- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] a Pharo talk from a ruby conference

by Craig Latta

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)

May 13, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Chris Muller

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(a)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

May 13, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Jan Vrany

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 >

May 13, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Alexandre Bergel

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.tymchuk(a)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

May 13, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Alexandre Bergel

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.tymchuk(a)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

May 13, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Igor Stasenko

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(a)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(a)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(a)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.

May 13, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Yuriy Tymchuk

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 <dastels(a)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(a)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(a)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 >> > >

May 13, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by David Astels

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(a)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(a)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 >

May 13, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Esteban A. Maringolo

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(a)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

May 13, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Sergi Reyner

2014-05-13 10:53 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)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

May 13, 2014