Re: Encapsulating the contents of container types

Patrick R. Michaud wrote: On Sat, Aug 20, 2011 at 04:41:08PM -0700, Darren Duncan wrote: I believe the general solution to this problem is to make all objects immutable, with the only exception being explicit references, and so mutating an object isn't an option; rather you have to derive a new

Re: Encapsulating the contents of container types

On Sat, Aug 20, 2011 at 04:41:08PM -0700, Darren Duncan wrote: > I believe the general solution to this problem is to make all > objects immutable, with the only exception being explicit > references, and so mutating an object isn't an option; rather you > have to derive a new object. > > "Values"

Re: Encapsulating the contents of container types

Carl Mäsak wrote: I ended up implementing a custom accessor method and a sub to deep-clone hashes, just to make sure that data belonging to readonly attributes doesn't get changed. This worries me. Concrete example (useless output left out): $ perl6 class A { has @.numbers; method add($n) { @

Re: Encapsulating the contents of container types

On Thu, Aug 18, 2011 at 04:06:47PM +0200, Carl Mäsak wrote: > I was working on the Little Animal Farm game yesterday, and wanted to > make it totally safe against tampering from the outside. (See > .) > > I ended up implementing a cus

Re: Encapsulating the contents of container types

On 2011-08-20 12:02, Damian Conway wrote: Carl asked: * What language components could be provided to put class implementors on the right path so that their classes end up encapsulated by default? Doing nothing should result in the safe behaviour (i.e. full encapsulation). You ought to have to

Re: Encapsulating the contents of container types

Carl asked: > * What do we mean when we say 'has @.a is readonly'? > What do we want it to mean? Not sure about "we", but I want that to mean that nothing outside the class can alter any component of @.a, no matter how deeply nested that component may be. > * Are we fine with references from re