Re: [Pharo-dev] a Pharo talk from a ruby conference
Morning, Livecoding is nice. I also like the idea of using the adjective "Agile" as it conveys coolness in the today developers mind: "Pharo, an agile programming environment and language for agile developers." Hilaire Le 13/05/2014 17:45, Craig Latta a écrit : > 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 -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] Immutable collections and encapsulation
On 13 May 2014, at 3:47 PM, David Astels 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. Agree 100% with David’s comment, it’s an issue of good OO design and there are valid cases to return immutable collections. I think most developers return internal collections, breaking encapsulation, but get away with it 99% of the time and only occasionally get burnt with a nasty bug or a deep mess. Cheers Carlo
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 wrote: 2014-05-13 14:28 GMT+01:00 Esteban A. Maringolo : 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] 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] 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] Immutable collections and encapsulation
2014-05-13 14:28 GMT+01:00 Esteban A. Maringolo : > 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] 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 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 : > 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] 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] 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] 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 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 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
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 List unmodifiableList(List 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 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] 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
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 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
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 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
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 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
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 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 > 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 : > >> 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
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 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 > 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 : >>> 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 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 : >> 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
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 : > 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
2014-05-13 10:53 GMT+01:00 Yuriy Tymchuk : > I’m looking in the OO-design concerns and it seams that Java guys are crazy > There's your answer :D Cheers, Sergi
[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] 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] 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
