On Tue, 2005-05-03 at 05:33, Thomas Sandla▀ wrote:
> Luke Palmer wrote:

> >>BTW, what does $.foo outside of class scope mean? 

> > It means: 

> >     BEGIN { die "Can't use \$.foo outside of class scope"; }
> That contradicts $Larry's statement: "By the way, this probably goes along
> with a policy of allowing $.foo, @.foo, and %.foo outside of the class as 
> well.
> These would not refer to the actual attribute, but would call $self.foo()
> underneath (except in the class that actually defines the attribute)."
> OK, he has got a 'probably' there. Would it be the one character saver
> $.foo == $_.foo outside class scope, $.foo == $?SELF.foo in methods
> of derived (or even unrelated?) classes and direct access to the instance
> variable in the class scope that has the corresponding 'has $.foo' 
> declaration?

If it's ever $_, then you have the problem where the code:

        given $someobj {
                when $.foo {...}

gets wrapped in a method later in the project:

        class X {
                method y {
                        given $someobj {
                                when $.foo {...}

Now you have two options: either it's ALWAYS $?SELF.foo because it's
inside a method (and thus, this code is now wrong), or it's only
$?SELF.foo if X or any ancestor has a $.foo, otherwise it's $_.foo.

I like the idea that $.foo ALWAYS means the $.foo in the current class.
Anything else gets very ugly later on.

On a side note about auto-accessors, if I say:

        class X {
                has $.foo;
        class Y is X {
                has %.foo;

What happens to the accessors for X.foo?

If there's no current plan, my suggestion would be that every
auto-accessor has an alias of the form "TYPE_NAME". That is, these hold

        has $foo; # Gets .Any_foo
        has int $foo; # Gets .int_foo
        has @foo; # Gets .Array_foo
        has @foo is MyArray; # Gets .MyArray_foo
        has $foo does X; # Hmmm... probably just .Any_foo

These should be automatically overridden by explicit method declarations
in this OR an ancestor class (to avoid mysterious bugs when you forget
that your "$.foo" is going to override your Any_foo method that has
nothing to do with an accessor), but should override inherited
auto-accessors... which of course means having to keep track of why a
method was created in the metaclass, but I don't think that's too hard.

Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback

Reply via email to