On Sat, Jul 31, 2010 at 08:23:29PM +0200, Carl Mäsak wrote: > * It has been decided that attribute slots of the type $!foo are only > allowed *syntactically* within the class block that declares them. > (The exception to this, I guess, is the 'trusts' directive.) But this > means that something like this anonymous method > > my $reveal-foo = method { say $!foo } > > isn't allowed. I think that's good, because it would provide a very > easy way to break encapsulation of an object; just call > $object.$reveal-foo() on it.
There is no $!foo. There is only $!Class::foo, and $!foo is a lexically scoped alias to it. This is necessary to allow privacy from your children to work: class Class { has $!foo; # the mere existance of $!foo is an implementation detail } class SubClass is Class { has $!foo; # hey why doesn't this work? } So $reveal-foo can't be defined because $!foo isn't even in scope. > * Today we discovered that it's possible to break encapsulation by > detaching a method from an object of one class, and calling that > method on an object of another class. Which means that breaking the > encapsulation of a foreign class is as easy as creating a custom class > with all of the same private attributes, and with a method to print > (or otherwise reveal) them. Calling such methods should fail, because the $!OtherClass:: attributes don't exist even if the shortnames are the same. > * It is my feeling that such encapsulation-breakage shouldn't be > allowed. Do you agree, p6l? It's not. > * 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)? > > I only see those three options: > > a. Allow this form of encapsulation breakage. > b. Disallow detaching of certain methods. > c. Disallow attaching of certain anonymous methods. > > I must confess I don't particularly like either option. I'm by no > means an OO expert. It would be interesting to hear your views on > this. Perl philosophy has always been "it's not that I have a shotgun, you just weren't invited, so stay out of my living room". I don't see any reason for Perl 6 to break with this - encapsulation should be about helping the programmer, not helping the sysadmin maintain system security. -sorear
signature.asc
Description: Digital signature