On Fri, 9 Sep 2011, Carl Mäsak wrote:
Patrick Michaud said something (I think AFK) that seems essential to
me: the non-rw-ness of these objects isn't a trait of *the object
itself*, it's a trait of *the context in which the object is used*.
In one sense that is true, but if that's the only
Thanks to everyone for your replies. I've been wanting to write a
summary + further thoughts for a while, but have been a bit
time-constrained.
The central tension in this issue is nicely captured by what Damian
wrote contrasted with what Stefan wrote:
Damian ():
Doing nothing should result in
Am 09.09.2011 12:44, schrieb Carl Mäsak:
Non-rw attributes, non-rw parameters, and non-rw return values all
share the same mechanism. Fine. Makes sense.
[...]
Non-rw-ness in this case should be all the way, not one level down.
(I hope I didn't change the meaning by stripping parts of your
Moritz ():
I think we should consider the implications of immutability-all-the-way-down
before we jump to any conclusions. In particular list cases where typical
Perl 5 code fails when ported to Perl 6.
Indeed. Clearly I'm missing at least one piece of the puzzle here.
Back to the
On Mon, Aug 22, 2011 at 06:39:25AM +0100, Nicholas Clark wrote:
Is it? If, at the implementation layer, all accesses to objects are actually
function calls called via vtables, then surely it's *relatively* simple to
change the vtable to replace
* mutator methods with methods which croak (the
On 08/21/2011 06:00 AM, Darren Duncan wrote:
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
Moritz Lenz wrote:
Moving into the direction of immutability doesn't help with the problem
at hand -- it only helps here if we force everything(*) to be immutable,
or at least encapsulating every mutable object into special types, like
Monads in Haskell.
(*) ok, not everything, but everything
The whole point of objects is to encapsulate state, accepting messages
which operate and report on that state. Making a new object every
time the state changes sort of defeats the purpose; I certainly
wouldn't call it object orientation done right.
Total immutability is very powerful, but it's
On Sun, Aug 21, 2011 at 08:10:46PM -0400, Mark J. Reed wrote:
The whole point of objects is to encapsulate state, accepting messages
which operate and report on that state. Making a new object every
time the state changes sort of defeats the purpose; I certainly
wouldn't call it object
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
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
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
http://masak.org/carl/yapc-eu-2011-little-animal-farm/talk.pdf.)
I ended up implementing a custom
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) {
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 of all
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
I was working on the Little Animal Farm game yesterday, and wanted to
make it totally safe against tampering from the outside. (See
http://masak.org/carl/yapc-eu-2011-little-animal-farm/talk.pdf.)
I ended up implementing a custom accessor method and a sub to
deep-clone hashes, just to make sure
On 2011-08-18 16:06, 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
http://masak.org/carl/yapc-eu-2011-little-animal-farm/talk.pdf.)
I ended up implementing a custom accessor method and a sub
17 matches
Mail list logo
