parseperl-discuss

[Parseperl-discuss] determining object types w/o executing???

[Mark E. T. <ma...@zz...>]

Howdy All,
	A very strange conglomeration events has led me here....
I'm very interested in attempting to determine what the type of an 
object would be at runtime - without actually having to run the program 
- say to determine available methods from a debugger (as mentioned in 
the recent article on perl.com).
	Clearly the code must be run to the point where the object is in the 
code to then 'ref' it to find out it's type - then something like PPI 
can be used to walk up the inheiritance tree collecting possible 
subroutines.
	Actually executing the program/script everytime just to determine the 
type of the object is a bummer - as who knows what the side-effects are 
of running & re-running the code over & over.
	Have you guys thought about how to tackle this?  It does seem the code 
has to be re-run everytime you would want to know the type of an object.
	I have a bizarro solution involving attributed-'my' variables to 
determine object types (replete w/code instrumentation via PPI) BUT 
re-running the code everytime sucks.
	Other then detecting whether the code has been modified before having 
to re-run it again have you guys come up with something to determine 
varaible types?
	It can't be possible... right???
		thanks!
			Mark

Re: [Parseperl-discuss] determining object types w/o executing???

[Adam K. <ad...@ph...>]

Mark Ethan Trostler wrote:
> Howdy All,
>     A very strange conglomeration events has led me here....
> I'm very interested in attempting to determine what the type of an 
> object would be at runtime - without actually having to run the program 
> - say to determine available methods from a debugger (as mentioned in 
> the recent article on perl.com).

Because Perl is loosely types, you can't really do this. A variable 
could contain just about anything.

>     Clearly the code must be run to the point where the object is in the 
> code to then 'ref' it to find out it's type - then something like PPI 
> can be used to walk up the inheiritance tree collecting possible 
> subroutines.

If you already have the the code loaded, then something like 
Class::Inspector does a pretty good job of working out the available 
methods by walking the ISA tree.

>     Actually executing the program/script everytime just to determine 
> the type of the object is a bummer - as who knows what the side-effects 
> are of running & re-running the code over & over.

Right. It's generally considered dangerous.

>     Have you guys thought about how to tackle this?  It does seem the 
> code has to be re-run everytime you would want to know the type of an 
> object.
>     I have a bizarro solution involving attributed-'my' variables to 
> determine object types (replete w/code instrumentation via PPI) BUT 
> re-running the code everytime sucks.
>     Other then detecting whether the code has been modified before 
> having to re-run it again have you guys come up with something to 
> determine varaible types?
>     It can't be possible... right???

Technically no, it's impossible. But then PPI is about dealing with the 
impossible :)

To repeat something you're going to be repeating quite a bit when people 
ask "can I" questions, if YOU (as a person) can look at a piece of code 
in a document and know what it is, then you should be able to write code 
with PPI to work it out programmatically.

But take something like

package Foo;

sub foo {
	my $self = shift;
	my $param = shift;
	...
}

Can you tell me what those are? You can probably guess that $self is 
going to be an object of type 'Foo' (or a subclass). But what is $param? 
You can't tell.

There's a range of situations in which you can guess reasonably well, 
for example...

my $foo = My::Class->new;

But in general, Perl vars are untyped, so no you can't tell.

Adam K

Re: [Parseperl-discuss] determining object types w/o executing???

[Mark E. T. <ma...@zz...>]

Which is partly why I just made Variable::Strongly::Typed.  With a touch 
more overhead ya can turn some of your variables into pre-known types.
Of course if you roll your own type via a sub. then all bets are off.
	Mark

SYNOPSIS

     use Variable::Strongly::Typed;

     my $int             :TYPE('int');       # must have an 'int' value
     my $float           :TYPE('float');     # must have a 'float' value
     my $string          :TYPE('string');    # must not be a reference
     my $file            :TYPE('IO::File');  # must be an IO::File
     my @array_of_ints   :TYPE('int');       # Each slot must contain an int
     my %hash_of_floats  :TYPE('float');     # Each value must be a float

     my @array_of_rgb :TYPE(\&red_green_blue); # my enumerated type

     # ... and later ...

     $int = 23;          # All is well
     $int = 'howdy!';    # This line will croak with a good error message

     $float = 3.23;              # All is well, nothing to see here
     $float = new XML::Parser;   # croak!

     $array_of_ints[23] = 44;    # Groovy
     $array_of_ints[12] = 'yah'; # croak!

     $hash_of_floats{pi} = 3.14159;      # no problem
     $hash_of_floats{e}  = new IO::File; # croak!

     # Return 1 if this val is RED, BLUE, or GREEN
     #   0 otherwise
     sub red_green_blue {
         local $_ = shift;

         /\A RED \z/xms || /\A BLUE \z/xms || /\A GREEN \z/xms;
     }

     $array_of_my_very_own_types[23] = 99;       # croak!
     $array_of_my_very_own_types[2] = 'BLUE';    # OK!



Adam Kennedy wrote:
> 
> 
> Mark Ethan Trostler wrote:
> 
>> Howdy All,
>>     A very strange conglomeration events has led me here....
>> I'm very interested in attempting to determine what the type of an 
>> object would be at runtime - without actually having to run the 
>> program - say to determine available methods from a debugger (as 
>> mentioned in the recent article on perl.com).
> 
> 
> Because Perl is loosely types, you can't really do this. A variable 
> could contain just about anything.
> 
>>     Clearly the code must be run to the point where the object is in 
>> the code to then 'ref' it to find out it's type - then something like 
>> PPI can be used to walk up the inheiritance tree collecting possible 
>> subroutines.
> 
> 
> If you already have the the code loaded, then something like 
> Class::Inspector does a pretty good job of working out the available 
> methods by walking the ISA tree.
> 
>>     Actually executing the program/script everytime just to determine 
>> the type of the object is a bummer - as who knows what the 
>> side-effects are of running & re-running the code over & over.
> 
> 
> Right. It's generally considered dangerous.
> 
>>     Have you guys thought about how to tackle this?  It does seem the 
>> code has to be re-run everytime you would want to know the type of an 
>> object.
>>     I have a bizarro solution involving attributed-'my' variables to 
>> determine object types (replete w/code instrumentation via PPI) BUT 
>> re-running the code everytime sucks.
>>     Other then detecting whether the code has been modified before 
>> having to re-run it again have you guys come up with something to 
>> determine varaible types?
>>     It can't be possible... right???
> 
> 
> Technically no, it's impossible. But then PPI is about dealing with the 
> impossible :)
> 
> To repeat something you're going to be repeating quite a bit when people 
> ask "can I" questions, if YOU (as a person) can look at a piece of code 
> in a document and know what it is, then you should be able to write code 
> with PPI to work it out programmatically.
> 
> But take something like
> 
> package Foo;
> 
> sub foo {
>     my $self = shift;
>     my $param = shift;
>     ...
> }
> 
> Can you tell me what those are? You can probably guess that $self is 
> going to be an object of type 'Foo' (or a subclass). But what is $param? 
> You can't tell.
> 
> There's a range of situations in which you can guess reasonably well, 
> for example...
> 
> my $foo = My::Class->new;
> 
> But in general, Perl vars are untyped, so no you can't tell.
> 
> Adam K
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Parseperl-discuss mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parseperl-discuss
>