[Pharo-dev] Immutable collections and encapsulation

David Astels dastels at icloud.com
Tue May 13 12:03:28 EDT 2014

If someone uses your class by using instVarNamed, they deserve any pain that results. Your job is to publish a clean public interface to your class, their job is to use that interface.

On May 13, 2014, at 10:29 AM, Chris Muller <asqueaker at gmail.com> wrote:

> You could answer a copy of the collection, so it won't matter
> internally if they try to add to it.  Or you could wrap the collection
> with operations too.
> However, doing that, I suppose someone could still write, "(someObject
> instVarNamed: 'internalCollection') add: junk.  So, why bother?
> Writing code that does nothing more than try to "protect" your
> program-state from bad code elsewhere is like inflicting static-typing
> on yourself.  Easier to simply not write the bad code in the first
> place.  :)
> On Tue, May 13, 2014 at 4:53 AM, Yuriy Tymchuk <yuriy.tymchuk at me.com> wrote:
>> Hi,
>> sorry if there was already this question, but I couldn’t find it anywhere.
>> I’m looking in the OO-design concerns and it seams that Java guys are crazy about returning the collection that is used for state of an objects. The only acceptable option is returning it in the immutable wrapper. As far as I know, pharo does not have immutable collections (except from intervals and symbols). Are we missing something important, or there is a philosophy behind the building blocks we have now, and the design we come up while using them.
>> Cheers.
>> Uko

More information about the Pharo-dev mailing list