[Pharo-dev] Immutable collections and encapsulation
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
Re: [Pharo-dev] a Pharo talk from a ruby conference
On 05/12/2014 10:54 PM, Nicolas Cellier wrote: But Smalltalk V was cheap, small, fairly well documented and worked on windows (DOS even). Yes, I even used it IIRC, but it was not gratis. And IMHO the only way to compete back then with the big boys (MS, Borland etc) was to either be gratis or open source. Because you couldn't match up when it came to advertising etc. Now, then came Sun with *both* a gratis download of the JDK *and* advertising as hell - bam. I mean... at the University we all used C++ in 1990s because it was free. I did have the luck to actually get to use VW then, but that took some effort from the University to get proper licenses. regards, Göran
[Pharo-dev] Alt-Space is Non-breaking S
… Which is extremely annoying when writing blocks with arguments on a norwegian OSX keyboard. | is Alt - 7, when I don’t release the Alt key before the following space, and a NBSP is inserted instead of a space character, which breaks both the parser and syntax highlighting. When doit’ing, you get the syntax error: [ :a | Unknown character -a ] (notice also the off-by-one indicator, it’s not the a, but the preceding space which is unknown). Would it be better if NBSP were treated equally to a normal space by the parser, or is there some keyboard binding I can revert? Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Immutable collections and encapsulation
2014-05-13 10:53 GMT+01:00 Yuriy Tymchuk yuriy.tymc...@me.com: I’m looking in the OO-design concerns and it seams that Java guys are crazy There's your answer :D Cheers, Sergi
Re: [Pharo-dev] Immutable collections and encapsulation
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.tymc...@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
Re: [Pharo-dev] Immutable collections and encapsulation
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 emaring...@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.tymc...@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
Re: [Pharo-dev] Immutable collections and encapsulation
Ok, I also forgot to tell my own opinion. If you as something for it’s model (or some other thing), you get it. Now it’s up to you if you want to modify it or not. The idea behind encapsulation rules is that you don’t force someone to rely on your internal data. So to allow someone add thing to your list you implement #add: method that takes one item and adds it to internal collection. But this doesn’t mean that you lock that collection from being modified when you return it. If someone want’s to write bad code he will do it anyway. One thing that you shouldn’t do is to enforce bad practices. But this question was really to gain knowledge from experienced computer scientists/engineers. Cheers Uko On 13 May 2014, at 15:47, David Astels dast...@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 emaring...@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.tymc...@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
Re: [Pharo-dev] Immutable collections and encapsulation
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 dast...@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 emaring...@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.tymc...@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.
Re: [Pharo-dev] Immutable collections and encapsulation
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). 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On May 13, 2014, at 5: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
Re: [Pharo-dev] Immutable collections and encapsulation
Also, I know that side-effect (e.g., adding or removing an element to a collection) does not work well with type-safety. E.g., Side-effect prevents many type system from being type-safe -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On May 13, 2014, at 5: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
Re: [Pharo-dev] Immutable collections and encapsulation
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
Re: [Pharo-dev] Immutable collections and encapsulation
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
Re: [Pharo-dev] a Pharo talk from a ruby conference
Hoi! Eliot wrote: Pharo isn't inspired by Smalltalk; it /is/ a Smalltalk. Trying to be mealy-mouthed about it and claiming inspiration, rather than proudly declaring its a Smalltalk is IMO as bad as apologizing for it being dead... We don't need to avoid the S word... Sean later wrote: ...it's a question of who you're marketing to. Since we're marketing to non-Smalltalkers (quite wise since 16% market penetration is the tipping point, and we're not there yet), clearly Pharo is Smalltalk- inspired is the thing to say. It's not any more or less true than the latter, just more useful in its context. And of course, with apologies to Alan, some of us think the name Smalltalk was a poor choice from day one (in 1971). Surely there are names which are suitably innocuous[1] but also convey some of the magic in providing computer support for the creative spirit in everyone[2]. Smalltalk is a vague and anemic name. From that weak starting point, the other baggage is even heavier (perhaps it's helpful to think of a balloon here? :). I would use a new name and not mention Smalltalk at all unless asked about it. At that point, I would proudly recount accomplishments. Whenever someone just blurts out that Smalltalk is dead, I always correct them, and it's not difficult. Smalltalk-inspired is a non-starter, because it implies (in all contexts) that there isn't a direct line of descent (there clearly is). I agree that it sounds mealy-mouthed, disingenuous. Smalltalk-derived would be the honest phrasing, and also sounds bad. Yeesh, if you have a problem with the Smalltalk name, don't be the first to mention it. :) Let's put more energy into a concise and intriguing description. I think the primary concepts are programming, dynamism and messaging. The word livecoding seems to resonate these days. If we're going to repeat a word twenty times, I would choose that one. :) It has a nice ring that draws people in. When they ask what livecoding is, you can describe dynamism, and then describe how the coding is structured (messaging, objects, etc.). thanks, -C [1] http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html [2] http://tinyurl.com/25s52qd (archive.org, Ingalls) -- Craig Latta www.netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
Re: [Pharo-dev] Immutable collections and encapsulation
Well, this is not what I exactly meant: http://www.tutorialspoint.com/java/util/collections_unmodifiablelist.htm The class Collection define the method: public static T ListT unmodifiableList(List? extends T list) It returns an instance of List. I do not think there is a type UnmodifiedList since it is difficult to type this kind of things. I think monad helps here, but I am not expert. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On May 13, 2014, at 11:19 AM, Jan Vrany jan.vr...@fit.cvut.cz wrote: 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
Re: [Pharo-dev] Immutable collections and encapsulation
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
Re: [Pharo-dev] developing games in Pharo
Good evening, Le 11/05/2014 17:21, Eliot Miranda a écrit : Hilaire, perhaps you can tell me whether touch support is OK or whether work needs to be done in the VM? I don't really know regarding the VM. I remember Bert did some experiment with multitouch on Etoys, but I can't tell if it was a temporary VM hack for iOS or something more structured for different multitouch devices. For sure works is needed at the image level to accommodate the widget to multitouch. Hilaire -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] developing games in Pharo
Le 11/05/2014 17:21, Eliot Miranda a écrit : On iPhone Apple expressly forbid JITs other than their own so until that changes the fastest VM on iPhone will be the Stack VM. When the iPad came out, I remember about anxiety in the community deploying Smalltalk application will be rejected by Apple... Hilaire -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] Github Pharo.org
fixed (since yesterday, but I forgot to send the mail :P) thanks for report Esteban On 13 May 2014, at 00:09, Nicolai Hess nicolaih...@web.de wrote: link for windows vm is wrong(Custom Downloads): http://files.pharo.org/vm/pharo/win/Pharo-VM-linux-stable.zip correct one: http://files.pharo.org/vm/pharo/win/Pharo-VM-win-stable.zip 2014-05-12 14:18 GMT+02:00 Esteban Lorenzano esteba...@gmail.com: I added it at download page: http://pharo.org/download now we have to improve all that infrastructure :) Esteban On 03 May 2014, at 19:06, p...@highoctane.be wrote: Am I blind or am I having a hard time spotting our stuff on GitHub from Pharo.org as well as some other properties that help us be visible? Meaning: https://github.com/orgs/pharo-project/ https://github.com/SquareBracketAssociates are very important places and aren't mentioned much. As are: https://github.com/tide-framework if someone wants to use Marina so use the Pharo power... Maybe can we add these and http://en.wikipedia.org/wiki/Pharo as well (as we bothered updating the page...) Also, in http://pharo.org/get-involved we sent people directly to the Fogbugz thing. We should mention this Penelope monkey as well: http://bugs.pharo.org/ Also, in documentation, people are doing webapps, so we need to add Dynamic Web Development with Seaside to http://pharo.org/documentation http://book.seaside.st/book And, we also must also add this gorgeous http://spec.st/ and Sebastian's Mapless supernice site as well. I do not have access to the CMS, so please some kind soul, do it :-) [or tell me how] Phil
Re: [Pharo-dev] Immutable collections and encapsulation
2014-05-13 14:28 GMT+01:00 Esteban A. Maringolo emaring...@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
Re: [Pharo-dev] Alt-Space is Non-breaking S
On Tue, May 13, 2014 at 4:08 AM, Henrik Johansen henrik.s.johan...@veloxit.no wrote: … Which is extremely annoying when writing blocks with arguments on a norwegian OSX keyboard. | is Alt - 7, when I don’t release the Alt key before the following space, and a NBSP is inserted instead of a space character, which breaks both the parser and syntax highlighting. When doit’ing, you get the syntax error: [ :a | Unknown character -a ] (notice also the off-by-one indicator, it’s not the a, but the preceding space which is unknown). Would it be better if NBSP were treated equally to a normal space by the parser, or is there some keyboard binding I can revert? I think getting the parser to accept NBSP is a really bad idea. If you want to export code to other dialects you can't rely on that happening. WTF is an accellerator key doing introducing an illegal sequence in the first place? Surely the key could insert a legal sequence? -- best, Eliot
Re: [Pharo-dev] a Pharo talk from a ruby conference
On 05/13/2014 10:45 AM, Craig Latta wrote: Hoi! Eliot wrote: Pharo isn't inspired by Smalltalk; it /is/ a Smalltalk. Trying to be mealy-mouthed about it and claiming inspiration, rather than proudly declaring its a Smalltalk is IMO as bad as apologizing for it being dead... We don't need to avoid the S word... Sean later wrote: ...it's a question of who you're marketing to. Since we're marketing to non-Smalltalkers (quite wise since 16% market penetration is the tipping point, and we're not there yet), clearly Pharo is Smalltalk- inspired is the thing to say. It's not any more or less true than the latter, just more useful in its context. And of course, with apologies to Alan, some of us think the name Smalltalk was a poor choice from day one (in 1971). Surely there are names which are suitably innocuous[1] but also convey some of the magic in providing computer support for the creative spirit in everyone[2]. Smalltalk is a vague and anemic name. From that weak starting point, the other baggage is even heavier (perhaps it's helpful to think of a balloon here? :). I would use a new name and not mention Smalltalk at all unless asked about it. At that point, I would proudly recount accomplishments. Whenever someone just blurts out that Smalltalk is dead, I always correct them, and it's not difficult. Smalltalk-inspired is a non-starter, because it implies (in all contexts) that there isn't a direct line of descent (there clearly is). I agree that it sounds mealy-mouthed, disingenuous. Smalltalk-derived would be the honest phrasing, and also sounds bad. Yeesh, if you have a problem with the Smalltalk name, don't be the first to mention it. :) Let's put more energy into a concise and intriguing description. I think the primary concepts are programming, dynamism and messaging. The word livecoding seems to resonate these days. If we're going to repeat a word twenty times, I would choose that one. :) It has a nice ring that draws people in. When they ask what livecoding is, you can describe dynamism, and then describe how the coding is structured (messaging, objects, etc.). thanks, -C [1] http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html [2] http://tinyurl.com/25s52qd (archive.org, Ingalls) -- Craig Latta www.netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) I would like to repent of my position that Pharo is Smalltalk vs. Pharo is Pharo. I have been watching videos on Self. I have also given my understanding some more thought. I do strongly dislike and argue against the Pharo is Smalltalk inspired. To me it is not accurate. As Craig said, Pharo is Smalltalk derived. It still runs Smalltalk code without conversion. It is still born from a Smalltalk. Pharo may be Self inspired or ??? inspired. But it is from Smalltalk therefore Smalltalk derived. Here is why I think it is okay to say Pharo is Pharo. And when Smalltalk is mentioned, explain that Pharo is Smalltalk derived. Pharo began as a Smalltalk with a vision to expand beyond Smalltalk-80 and add features inspired by other modern programming languages. I still believe that none of this makes Pharo not a Smalltalk. But here is why I in my current understanding would change to Pharo is Pharo. Smalltalk is a language, name, environment and implementation created by a certain group of people. Pharo is not that group of people. Pharo began with an artifact from those people. So the question could be presented, does Pharo have the right to conscript the name Smalltalk and extend its vision, implementation and meaning. Conservatively, I would say it is fairer to Pharo and to Smalltalk to let Pharo be Pharo and have liberty in its vision, implementation, definitions and marketing decisions. Just a few more thoughts to toss into the fray. Jimmie
Re: [Pharo-dev] Immutable collections and encapsulation
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.rey...@gmail.com wrote: 2014-05-13 14:28 GMT+01:00 Esteban A. Maringolo emaring...@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
