Re: Encapsulating the contents of container types

2011-08-21 Thread Nicholas Clark
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 or

Re: Encapsulating the contents of container types

2011-08-21 Thread Mark J. Reed
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

Re: Encapsulating the contents of container types

2011-08-21 Thread Darren Duncan
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 th

Re: Encapsulating the contents of container types

2011-08-21 Thread Moritz Lenz
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

[perl6/specs] 3ac109: Disallow Pod blocks inside of Formatting Codes.

2011-08-21 Thread noreply
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 3ac10981f10ec46adb5dbc6f54aed6a628711150 https://github.com/perl6/specs/commit/3ac10981f10ec46adb5dbc6f54aed6a628711150 Author: Tadeusz SoĊ›nierz Date: 2011-08-21 (Sun, 21 Aug 2011) Changed paths: M