develooper Front page | perl.perl6.language.objects | Postings from November 2001

Re: Stupid Newbie Question

Thread Previous | Thread Next
From:
John Rudd
Date:
November 15, 2001 17:50
Subject:
Re: Stupid Newbie Question
Message ID:
3BF470AE.D9078285@cats.ucsc.edu
Damian Conway wrote:
> 
> Schwern explained:
> 
>    > Going away?  No way, it's SPREADING!  We might wind up with AUTOGLOB, too.
>    >
>    > http://dev.perl.org/rfc/324.pod
> 
> Though it won't be called AUTOGLOB (globs *are* going away),
> and its semantics might be closer to those portrayed in:
> 
>         http://www.yetanother.org/damian/Perl5+i/autovivify.html
> 
> Damian


I've been turning these two items over in my head for the last few days,
and wondering about the feasability of adding something to their
arguments:

some indication of who invoked the request.


So, for example, lets say I have an object $foo, which is an instance of
Class A.  In one method, foo tries to access an instance variable of
$bar, an instance of Class B (not inherited from Class A).  If $bar's
instance variables are somehow hidden, I could then have the Class B
auto(vivify|glob) routine perform checks on the identity and heritage of
$foo, and then decide what to do about the request.

That way you could choose to impliment Smalltalk or C++ style
protections (public, private, protected, etc) in the same way that I'm
using AUTOLOAD to impliment Smalltalk/Objective-C style instance/class
seperations.  So, for Smalltalk type semantics, if $foo != $bar, the
request will throw some sort of exeption indicating that $foo isn't
allowed to see $bar's instance variables.  But, if $foo == $bar, then
the actual value will be found and returned.

The question in my brain, since I don't know perl's internals in very
much detail, is how hard is it to figure out who the caller was?  It's
not just a matter of knowing what package the invoking subroutine
belonged to, because instances of the same class might have have access
to eachother's instance variables (ala Smalltalk).  It further
complicates things if you want to extend it to include C++ style
"friend" functions (I don't, but others might).



Oh, and, how does autovivify work wrt to class/package variables?  I
mean, with an instance, you access instance variables via $foo->{blah}
and this will look for some scalar value, so I assume that the first
argument will be a reference to a scalar, and the second value will be
something like "$foo->{blah}".  What if, instead, I did
"Class->{blah}"?  With AUTOLOAD I can tell the difference between class
and instance methods by asking if the first argument was a reference or
not.  If it was, then it was an instance, if not, then it's a
class/package.  How will that be handled here?

(yes, I know you can emulate class variables via package globals like
$Class::blah, but I'm trying to look at it in a more uniform point of
view so that you can fully treat Classes themselves as being objects)


-- 
John "kzin" Rudd                       http://people.ucsc.edu/~jrudd
Truth decays into beauty, while beauty soon becomes merely charm. Charm
ends up as strangeness, and even that doesn't last. (Physics of Quarks)
   -----===== Kein Mitleid Fu:r MicroSoft (www.kmfms.com) ======-----

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About