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
