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
true:
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
