Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

jnthn++ points out in meatspace that the invocant parameter has a constraint (by spec but not in Rakudo), which will carry over to the new class. Which means that only objects of child classes will signature-bind anyway. // Carl

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

On 2010-07-31 20:23, Carl Mäsak wrote: * 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

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

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

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

Carl Mäsak wrote: > * It is my feeling that such encapsulation-breakage shouldn't be > allowed. Do you agree, p6l? Time may proof me wrong, but I think it's not such a big issue. Note that encapsulation can be broken in many ways already, wither with MONKEY_TYPING or by using introspection techni

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

Carl (>>), sorear (>): >> * 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 >> >>    

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 14:38 , Stefan O'Rear wrote: > On Sat, Jul 31, 2010 at 02:36:02PM -0400, Brandon S Allbery KF8NH wrote: >> The whole concept of detaching and attaching methods seems suspect to me; in >> particular, attaching a method from a class not declar

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

On Sat, Jul 31, 2010 at 02:36:02PM -0400, Brandon S Allbery KF8NH wrote: > On 7/31/10 14:23 , Carl Mäsak wrote: > > 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 par

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

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 lik

Re: Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/31/10 14:23 , Carl Mäsak wrote: > 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 n

Breaking encapsulation by detaching a private-variable-accessing method from one object and calling it on another

Here's a case where a bug report stumped me and made me feel I'm missing something: I'll give a somewhat summarized version of the above page, which gradually turns into a set of questions and not enough answers: * It has been decided that a