Well, an issue of good OO design or not. Returning a mutable collection breaks encapsulation. My initial question is whether the collection is simply a detail of the implementation or part of the external interface you want to expose. If the former, hide the collection and expose operations that provide what’s truly needed. If the latter, then you might need immutable collections. Java devs aren’t crazy… they just tend not to understand OO very well. Dave On May 13, 2014, at 8:28 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

I think it is more an issue of design.

If your Invoice has a collection of "Items", you shouldn't manipulate the collection directly and instead use accessor/operator methods.

I wouldn't restrict having the option of direct manipulation of the collection, but it is a nice thing to have covered by some LINT rules. :)

Regards,

Esteban A. Maringolo

2014-05-13 6:53 GMT-03:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:

...

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

indeed. simply don't expose unwanted operations to the user. there's many ways to do that and wrapping it is just one of it. On 13 May 2014 15:47, David Astels <dastels@icloud.com> wrote:

Well, an issue of good OO design or not. Returning a mutable collection breaks encapsulation. My initial question is whether the collection is simply a detail of the implementation or part of the external interface you want to expose. If the former, hide the collection and expose operations that provide what’s truly needed. If the latter, then you might need immutable collections.

Java devs aren’t crazy… they just tend not to understand OO very well.

Dave

On May 13, 2014, at 8:28 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

...

I think it is more an issue of design.

If your Invoice has a collection of "Items", you shouldn't manipulate the collection directly and instead use accessor/operator methods.

I wouldn't restrict having the option of direct manipulation of the collection, but it is a nice thing to have covered by some LINT rules. :)

Regards,

Esteban A. Maringolo

2014-05-13 6:53 GMT-03:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:

...

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

-- Best regards, Igor Stasenko.

But how well "unmodifiable" collection is? Should it protect also from modifying the items themselves? Or any object(s) accessible through items? Or any objects accessible through all objects accessible through items? Because without propagating immutability how you cannot prove that you actually made things "safe"? There was a work by Jean-Baptiste exploring that direction, by introducing special kind of references (immutable references).. which is a special view on object that does not allows its modification and also has an option to propagate same kind of property on all references it may give away. This is done at VM level, sure thing.. and sure thing there is a performance cost.. but again, if you so desperately need "safety", just making immutable collections is not a solution. It is much more involved :) -- Best regards, Igor Stasenko.

Hi Obviously this all depends on context and what is trying to be achieved ;) In certain cases all we want to do is ensure the container is not modifiable but don’t mind access to the held objects within. if the internal data is immutable (e.g. a representation of an error) then we don’t care if they have access to this data but we may care that they modify the collection that holds these objects. You then need to weigh in with a pro/con of using unmodifiable collections versus a copy; most of the time a copy is all you need as the collections will be small. If the context requires for some (odd) reason complete immutability and you’re happy to pay the price in terms of space/time or additional complexity then there are other solutions from deepCopy, to something like Worlds (http://www.vpri.org/pdf/tr2011001_final_worlds.pdf , http://www.vpri.org/pdf/m2013002_experiments.pdf ) or maybe some weird use of software transactional memory. The point is though that there are valid cases where an immutable container is all you want; Java provides this as a library out of the box, if developers mis-use it then it’s not an issue with the language but rather an OO design flaw by the programmer as was previously mentioned. By the same token if Smalltalk developers only use #copy to achieve similar semantics then the Java solution is more elegant in terms of performance but potentially confusing with regards to the change in behaviour of the returned collection (can’t mutate the collection now which could break contract of collection). Cheers Carlo On 14 May 2014, at 1:02 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote: 2014-05-14 12:50 GMT+02:00 Igor Stasenko <siguctua@gmail.com>: But how well "unmodifiable" collection is? Should it protect also from modifying the items themselves? Or any object(s) accessible through items? Or any objects accessible through all objects accessible through items? Because without propagating immutability how you cannot prove that you actually made things "safe"? There was a work by Jean-Baptiste exploring that direction, by introducing special kind of references (immutable references).. which is a special view on object that does not allows its modification and also has an option to propagate same kind of property on all references it may give away. This is done at VM level, sure thing.. and sure thing there is a performance cost.. but again, if you so desperately need "safety", just making immutable collections is not a solution. It is much more involved :) +1 Even a veryDeepCopy (sic...) would not be enough for safety. We are dynamic and the behavior can change at any moment. So you'd need to also duplicate the whole class hierarchy of each and every object in the graph. Or lock if you prefer lock to copy, but problem remains the same... -- Best regards, Igor Stasenko.

For objects - knowing if they have been modified or not could have big benefits in performance when you want to “commit” anything in your object graph to an object database. For collections - In NeXT / Apple WebObjects we’ve always made a distinction: NSArray / NSMutableArray NSSet / NSMutableSet NSDictionary / NSMutableDictionary Each one of these has a “mutableClone” and “immutableClone” method. It was this way when it was Objective-C and it remained this way when we went to Java. We never use the standard Java collections. The mutable classes always inherit from the immutable ones as you can see here: http://wocommunity.org/documents/javadoc/WebObjects/5.4.2/ that makes OO sense in that the mutable versions do everything the immutable can… plus you can “add” or “remove” as well. Here we are only talking about the reference to objects… the objects themselves are still mutable. In general it seems nice to make this distinction in collections. For example… suppose a “Company” has “Employees.” But somebody later is playing with the array of “employees” and wants to add one. Do they know that later someone looking at the Company will see a new employee? maybe they wouldn’t. AARON ROSENZWEIG / Chat 'n Bike e: aaron@chatnbike.com t: (301) 956-2319 On May 14, 2014, at 7:45 AM, Marcus Denker <marcus.denker@inria.fr> wrote:

On 14 May 2014, at 13:27, Carlo <snoobabk@gmail.com> wrote:

...

Hi

Obviously this all depends on context and what is trying to be achieved ;) In certain cases all we want to do is ensure the container is not modifiable but don’t mind access to the held objects within. if the internal data is immutable (e.g. a representation of an error) then we don’t care if they have access to this data but we may care that they modify the collection that holds these objects. You then need to weigh in with a pro/con of using unmodifiable collections versus a copy; most of the time a copy is all you need as the collections will be small.

If the context requires for some (odd) reason complete immutability and you’re happy to pay the price in terms of space/time or additional complexity then there are other solutions from deepCopy, to something like Worlds (http://www.vpri.org/pdf/tr2011001_final_worlds.pdf , http://www.vpri.org/pdf/m2013002_experiments.pdf ) or maybe some weird use of software transactional memory.

We did an experiment with read-only references some time ago:

http://rmod.inria.fr/web/publications/bib?query=Arna10a&display=abstract

The idea is that we hacked the VM to have references-as-objects that can override behaviour transparently.

Marcus

Hi The advantage is that there is a standard library for implementing efficient unmodifiable “read-only” collections. Just because the Java ‘crowd’ have it doesn’t mean they misuse it (or that they do not understand OO); there are the odd occasions when it is useful to tighten down your interfaces and by creating a “read-only” view e.g. you want to return a list of errors while ensuring that none of your clients modify (add or remove) the underlying list. This can be (efficiently) achieved in Java by wrapping your collection in an unmodifiable list as access “reads-through” to the wrapped collection. My understanding is that the common idiom for Smalltalk code is to rather perform a copy of the collection (as was suggested by others), this could be very inefficient but needs to be weighed in versus introducing an unmodifiable collection that breaks the Liskov substitution principle and could potentially have confusing concurrency issues (e.g. unmodifiable collection is “read-through” which means that underlying data structure can be modified which will affect the unmodifiable collection. On the other hand having a good implementation of persistent data structures in Smalltalk would be interesting to play with… My 2c Cheers Carlo Still, after stating all of the above, I have used Java’s unmodifiable collections to prevent clients modifying results, especially when I know there is a chain of clients that may process this collection and perhaps modify the collection. On 13 May 2014, at 7:55 PM, Sergi Reyner <sergi.reyner@gmail.com> wrote: 2014-05-13 14:28 GMT+01:00 Esteban A. Maringolo <emaringolo@gmail.com>: I wouldn't restrict having the option of direct manipulation of the collection, but it is a nice thing to have covered by some LINT rules. :) That´s what I meant, in a convoluted way, with "they are crazy". For me, Java is about restrictions on restrictions on restrictions, which in the end don´t feel like giving me any advantage. In this case, if I want to modify the returned collection it should be my business. I may have a reason to do so. Then again, Java is not a dynamic language and so on... :) Cheers, Sergi

On 13/05/14 15:50, Alexandre Bergel wrote:

I got an interest some years ago, to see if Context-Oriented-Programming would help to have immutable collections.

Apparently, Java supports immutability at runtime (i.e., there is no class ImmutableArrayList as far as I know).

Actually there is. Have a look at java.util.Collections, java.util.Collections.UnmodifiableList/UnmodifiableRandomAccessList in particular. Many libraries define their own immutable collections as far as I have seen. There's no support for object immutability in the OpenJDK-based JVMs. Cheers, Jan

So, there is no good design for immutable collections as far as I know. I read something about that on Doug Lea web page.

Cheers, Alexandre

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@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@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