Carl (>>), Moritz (>):
>> * If it isn't allowed, which of the two steps is disallowed?
>> *Detaching* a method containing references to private accessor slots
>> (thereby extending the syntactic restriction of "no private accessors
>> outside of the class block"), or *attaching* an anonymous method to an
>> object belonging to a different class than the one from which it was
>> detached (thereby by necessity having to complicate anonymous methods
>> somewhat)?
>
> There's a third possiblity - $!foo being bound to the $!foo attribute of
> the lexically enclosing class at compile-time. So that re-attaching
> methods make them still refer to the old attribute. Not sure if it's a
> good idea, just food for thought.
That's indeed what Stefan proposed as well, and what I currently
believe to be the right way of looking at this. The fact that you
don't mention an error condition in connection to the accessing of the
old attribute makes me realize yet another thing:
class Parent { has $!a; method foo { say $!a } }
class Child is Parent { has $!a }
my $child = Child.new( :a(42), Parent{ :a(5) } );
my $parent-foo = Parent.^can('foo');
$child.$parent-foo(); # works, prints "5\n"
Or, in words, just because one detaches/re-attaches a method doesn't
automatically mean that private attribute accesses result in an error.
Specifically, they don't in child classes.
// Carl
