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 <asquea...@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.tymc...@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 >
