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.


Attachment: signature.asc
Description: Digital signature

Reply via email to