January 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] parsing a file / stream API advice

by Johan Fabry

Hi Daniel, I have disclaimers as the 2 previous responses, this is my feeling about the matter. :-) I would prefer to think purely in terms of the API that you want to use when reading the file, and have that clear and explicit. So do NOT subclass Stream nor do a class extension with #nextFoo. I would think in terms of the Stream API when doing that, and reuse as many message names as possible, because it is a fairly âstandardâ API. So: option 1, without the use of doesNotUnderstand. > On Jan 18, 2015, at 06:11, Daniel Lyons <fusion(a)storytotell.org> wrote: > > This is an OO design question. > > For my task, I have some objects and a particular file format that encodes them. I want to be able to read the file and create those objects. The Stream API seems like the right way to do this, but I'm not sure how to encapsulate my code. I see these options: > > â¢ Create a new class (subclass of Object) that implements #next to return the next object in some underlying stream. > > Pro: very simple, one place with all the code. Con: what about the rest of the Stream and/or Collection APIs? Is it wise to delegate everything else to the underlying stream with #doesNotUnderstand:? > > â¢ Create a new class, subclass of Stream, that implements #next like the above. > > Pro: still pretty simple, not sure what is needed to implement the API completely (I did add a method #atEnd). Con: not sure if more methods are missing; unclear about initialization (overrode class>>#on: to call #basicNew). This seems close to the right approach but I'm unsure. > > â¢ Create a method #nextFoo on the existing Stream class. > > Pro: very simpleâno new class. Con: nextFoo doesn't integrate well with the rest of the API (#do: for instance), not sure this is clean or wise. > > â¢ Ignore the Stream classes altogether. > > Pro: No chance of misundestanding. :) Con: everything else. > > Advice? > > Thanks for your time, > > â > Daniel Lyons > > > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Jan. 18, 2015

Re: [Pharo-users] InfoWorld on Redline Smalltalk

by Johan Fabry

+1 on all of this, > On Jan 18, 2015, at 12:06, stepharo <stepharo(a)free.fr> wrote: > > Hello people > > do you realize that you are poluting the ****PHARO**** users mailing-list? > What is the message we sent to users that are happily hacking in Pharo. > The user mailing-list not an open bar to talk about any topics. > > We will create a Pharo-chat mailing-list. > And all these discussions should be moved there. > > Stef ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Jan. 18, 2015

Re: [Pharo-users] InfoWorld on Redline Smalltalk

by horrido

Let us know when Pharo-chat is ready. I'll move everything there. Thanks. stepharo wrote > Hello people > > do you realize that you are poluting the ****PHARO**** users mailing-list? > What is the message we sent to users that are happily hacking in Pharo. > The user mailing-list not an open bar to talk about any topics. > > We will create a Pharo-chat mailing-list. > And all these discussions should be moved there. > > Stef > > > Le 18/1/15 01:00, horrido a Ã©crit : >> Thanks for this link! I always thought there was something not right >> about >> Angular, and this article (and its links) clearly lay out the issue. >> >> Obviously, I think Amber is a better solution. >> >> The one big takeaway from these anti-Angular articles, I think, is >> this... >> >> /IT management often make stupid choices based on fad, fashion, and >> laziness./ They can't be bothered to do the actual research and >> investigation to see which technology best fits their goals and >> objectives. >> Presumably, one of their chief objectives is to improve productivity and >> save on (labour) costs. How can you meet this objective without at least >> trying one of the premier productivity technologies on the market, >> namely, >> Smalltalk? How can you not have heard the oft-repeated claims about >> Smalltalk's superlative productivity over the years? They've only been >> made >> year after year since the 1980s. >> >> All that is required is to run a pilot Smalltalk program. This will >> definitively answer the question: How much more productive can you be in >> developing software? >> >> Generalissimo >> >> >> > sebastian@ > wrote >>>> On Jan 17, 2015, at 3:18 PM, kilon alios < >>> kilon.alios@ >>> > wrote: >>>> So overall I doubt that Smalltalk will ever be a big hit on JVM or >>>> Javascript. >>> Everybody is a looser if you frame it in that perspective. >>> >>> That game is not interesting, nor strategy wise. >>> >>> An interesting alternative is to create the opportunity for people to >>> take >>> their bite on the Java market and if they can do it, as small as it >>> might >>> be thatâs all that really counts. >>> >>> James is already one of those someone will make it when the demand is >>> felt. >>> >>> If Redline Smalltalk saves significant costs to a company that has >>> invested heavy in something JVM-ish then you will have their attention. >>> >>> Productivity is one of the strongest opportunities for Smalltalk unless >>> our tools UI/UX sucks so bad it get deteriorated or the world catches >>> up. >>> >>> And we have control over the UI/UX we provide. >>> >>> Have you ever thought that AngularJS is essentially a Google strategy to >>> bite Javaâs market >>> <http://www.quirksmode.org/blog/archives/2015/01/the_problem_wit.html>? >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799678p4800193.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> -- View this message in context: http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799678p4800233.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 18, 2015

Re: [Pharo-users] parsing a file / stream API advice

by Ben Coman

Daniel, I don't have a definitive answer for you. I took an interest to browse what was built into Pharo (using Tools > Finder > Classes and searching for "stream" and also for "read") and looking at the hierarchy of several results it seems there is a mix. I suppose the fall back position is "do the simplest thing that works." On Sun, Jan 18, 2015 at 1:11 PM, Daniel Lyons <fusion(a)storytotell.org> wrote: > This is an OO design question. > > For my task, I have some objects and a particular file format that encodes > them. I want to be able to read the file and create those objects. The > Stream API seems like the right way to do this, but I'm not sure how to > encapsulate my code. I see these options: > > â¢ Create a new class (subclass of Object) that implements #next to return > the next object in some underlying stream. > > Pro: very simple, one place with all the code. Con: what about the rest of > the Stream and/or Collection APIs? Is it wise to delegate everything else > to the underlying stream with #doesNotUnderstand:? > ImageReadWriter seems an example of this - but I don't think it delegates #doesNotUnderstand: - it looks like it implements the full protocol in the "stream access" protocol. It has an instance variable /stream/ that it forwards t > > â¢ Create a new class, subclass of Stream, that implements #next like the > above. > > Pro: still pretty simple, not sure what is needed to implement the API > completely (I did add a method #atEnd). Con: not sure if more methods are > missing; unclear about initialization (overrode class>>#on: to call > #basicNew). This seems close to the right approach but I'm unsure. > > â¢ Create a method #nextFoo on the existing Stream class. > JPEGReadStream and TxCharacterStream seem examples of this. cheers -ben > Pro: very simpleâno new class. Con: nextFoo doesn't integrate well with > the rest of the API (#do: for instance), not sure this is clean or wise. > > â¢ Ignore the Stream classes altogether. > > Pro: No chance of misundestanding. :) Con: everything else. > > Advice? > > Thanks for your time, > > â > Daniel Lyons > > > > >

Jan. 18, 2015

Re: [Pharo-users] Blitzkrieg!

by horrido

This is a fine line to tread. I have several problems with self-censorship: First of all, "Generalissimo" is just a handle. My previous handle, "horrido", was surely objectionable as well, since it's a play on the battle cry associated with the WWII German Luftwaffe ( Horrido: Fighter Aces of the Luftwaffe <http://www.amazon.ca/Horrido-Luftwaffe-Raymond-F-Toliver/dp/0553126636> ). I admit to being a WWII buff. I have been for many years. Should I apologize for this? Second, I am firmly and philosophically opposed to Political Correctness. I find it intellectually offensive to my very core. I guess that would make me a lousy politician. One thing that no one can accuse me of is being intellectually dishonest. Third, my self-censorship is hardly different from what Muslim terrorists were trying to achieve in Paris last week. Free expression should be protected (as long as it is not foul or vulgar). Any language you use will offend /someone somewhere/ at /some time/ in the world. I try to be sensible and I try to be artistically honest. This is reflected in my writings. There will always be people who find my style distasteful. There isn't much I can do about that. sebastian(a)flowingconcept.com wrote > Sometimes you want to polarise people but there is nothing interesting as > output of this particular one, please consider review that inner joke > Richard > > So I agree, that this particular vocabulary will polarise people in an > inconvenient way. > > > > >> On Jan 18, 2015, at 6:30 AM, > jtuchel@ > wrote: >> >> Horrido, >> >> You are aware that there are regions on this planet where mails >> containing vocabulary like Blitzkrieg or Genaralissimo will evoke >> reactions that will not help at ll. You are at risk to simply be ignored >> in the best case. In the worst case, people will hsake their heads and >> associate Smalltalk with a certain kind of political spam they receive >> from time to time. >> >> Joachim >> >> >> Von: horrido <mailto: > horrido.hobbies@ > > >> Gesendet: âSamstagâ, â17â. âJanuarâ â2015 â16â:â15 >> An: Any question about pharo is welcome <mailto: > pharo-users@.pharo > > >> >> http://horridohobbies.tumblr.com/ >> <http://horridohobbies.tumblr.com/> >> >> *Today is the one-month anniversary of the SRP.* We have made good >> progress, >> but there is still much work ahead of us. >> >> Shortly, I will be seeking corporate sponsorship. As well, I'm trying to >> coordinate activities with the Smalltalk Foundation. >> >> Later this summer, I will be pushing my "Small Minds Initiative," a >> sub-campaign of the SRP to get Smalltalk into the classroom. I will begin >> with the Toronto District School Board. >> >> Are we pumped yet?! >> >> Generalissimo >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Blitzkrieg-tp4800165.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/Blitzkrieg-tp4800165p4800229.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 18, 2015

Re: [Pharo-users] Blitzkrieg!

by Sebastian Sastre

Sometimes you want to polarise people but there is nothing interesting as output of this particular one, please consider review that inner joke Richard So I agree, that this particular vocabulary will polarise people in an inconvenient way. > On Jan 18, 2015, at 6:30 AM, jtuchel(a)objektfabrik.de wrote: > > Horrido, > > You are aware that there are regions on this planet where mails containing vocabulary like Blitzkrieg or Genaralissimo will evoke reactions that will not help at ll. You are at risk to simply be ignored in the best case. In the worst case, people will hsake their heads and associate Smalltalk with a certain kind of political spam they receive from time to time. > > Joachim > > > Von: horrido <mailto:horrido.hobbies@gmail.com> > Gesendet: âSamstagâ, â17â. âJanuarâ â2015 â16â:â15 > An: Any question about pharo is welcome <mailto:pharo-users@lists.pharo.org> > > http://horridohobbies.tumblr.com/ <http://horridohobbies.tumblr.com/> > > *Today is the one-month anniversary of the SRP.* We have made good progress, > but there is still much work ahead of us. > > Shortly, I will be seeking corporate sponsorship. As well, I'm trying to > coordinate activities with the Smalltalk Foundation. > > Later this summer, I will be pushing my "Small Minds Initiative," a > sub-campaign of the SRP to get Smalltalk into the classroom. I will begin > with the Toronto District School Board. > > Are we pumped yet?! > > Generalissimo > > > > -- > View this message in context: http://forum.world.st/Blitzkrieg-tp4800165.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 18, 2015

Re: [Pharo-users] parsing a file / stream API advice

by Sven Van Caekenberghe

Hi Daniel, I am not sure that there is any right answer. If you want to see examples, you can look how I did it in NeoCSV, NeoJSON or STON. They are all similar, but there are small differences. You should do what feels best to you. Object design is (much more) about messaging that about class hierarchies. If some object understands the messages that another object wants to send it, then is compatible, independent of class hierarchy. It only makes sense to subclass if you gain something, like an implementation and if the superclass was designed to be subclasses. Often you can just implement a couple of messages (say, a small part of the stream protocol) and your object can be used (say, pass as a stream). It also makes sense to reuse message selectors for similar behaviour. Most of my parsers understand #next, #atEnd, #close, #upToEnd - it helps other to immediately understand what you mean. HTH, Sven > On 18 Jan 2015, at 06:11, Daniel Lyons <fusion(a)storytotell.org> wrote: > > This is an OO design question. > > For my task, I have some objects and a particular file format that encodes them. I want to be able to read the file and create those objects. The Stream API seems like the right way to do this, but I'm not sure how to encapsulate my code. I see these options: > > â¢ Create a new class (subclass of Object) that implements #next to return the next object in some underlying stream. > > Pro: very simple, one place with all the code. Con: what about the rest of the Stream and/or Collection APIs? Is it wise to delegate everything else to the underlying stream with #doesNotUnderstand:? > > â¢ Create a new class, subclass of Stream, that implements #next like the above. > > Pro: still pretty simple, not sure what is needed to implement the API completely (I did add a method #atEnd). Con: not sure if more methods are missing; unclear about initialization (overrode class>>#on: to call #basicNew). This seems close to the right approach but I'm unsure. > > â¢ Create a method #nextFoo on the existing Stream class. > > Pro: very simpleâno new class. Con: nextFoo doesn't integrate well with the rest of the API (#do: for instance), not sure this is clean or wise. > > â¢ Ignore the Stream classes altogether. > > Pro: No chance of misundestanding. :) Con: everything else. > > Advice? > > Thanks for your time, > > â > Daniel Lyons > > > >

Jan. 18, 2015

Re: [Pharo-users] Nautilus plugin with new menu entries

by stepharo

Hi hernan did you see that I cleaned, fixed and documented the plugins in Pharo 40? Sef Le 18/1/15 06:32, HernÃ¡n Morales Durand a Ã©crit : > Hi, > If you are using Pharo 3 you may install a Nautilus plugin I did which > implements the following menu item features: > > - Jump to the superclass of the currently selected class. > - Explore all the instances of the currently selected class. > - Send #release and #initialize to the currently selected class > - Send (#perform:) the selected unary method to a new instance of the > currently selected class. > > To install evaluate: > > Gofer it > smalltalkhubUser: 'hernan' project: 'HernanPlugins'; > package: 'HernanPlugins'; > load. > > Repository: http://www.smalltalkhub.com/#!/~hernan/HernanPlugins > <http://www.smalltalkhub.com/#%21/%7Ehernan/HernanPlugins> > > Cheers, > > HernÃ¡n >

Jan. 18, 2015

Re: [Pharo-users] InfoWorld on Redline Smalltalk

by stepharo

Hello people do you realize that you are poluting the ****PHARO**** users mailing-list? What is the message we sent to users that are happily hacking in Pharo. The user mailing-list not an open bar to talk about any topics. We will create a Pharo-chat mailing-list. And all these discussions should be moved there. Stef Le 18/1/15 01:00, horrido a Ã©crit : > Thanks for this link! I always thought there was something not right about > Angular, and this article (and its links) clearly lay out the issue. > > Obviously, I think Amber is a better solution. > > The one big takeaway from these anti-Angular articles, I think, is this... > > /IT management often make stupid choices based on fad, fashion, and > laziness./ They can't be bothered to do the actual research and > investigation to see which technology best fits their goals and objectives. > Presumably, one of their chief objectives is to improve productivity and > save on (labour) costs. How can you meet this objective without at least > trying one of the premier productivity technologies on the market, namely, > Smalltalk? How can you not have heard the oft-repeated claims about > Smalltalk's superlative productivity over the years? They've only been made > year after year since the 1980s. > > All that is required is to run a pilot Smalltalk program. This will > definitively answer the question: How much more productive can you be in > developing software? > > Generalissimo > > > sebastian(a)flowingconcept.com wrote >>> On Jan 17, 2015, at 3:18 PM, kilon alios < >> kilon.alios@ >> > wrote: >>> So overall I doubt that Smalltalk will ever be a big hit on JVM or >>> Javascript. >> Everybody is a looser if you frame it in that perspective. >> >> That game is not interesting, nor strategy wise. >> >> An interesting alternative is to create the opportunity for people to take >> their bite on the Java market and if they can do it, as small as it might >> be thatâs all that really counts. >> >> James is already one of those someone will make it when the demand is >> felt. >> >> If Redline Smalltalk saves significant costs to a company that has >> invested heavy in something JVM-ish then you will have their attention. >> >> Productivity is one of the strongest opportunities for Smalltalk unless >> our tools UI/UX sucks so bad it get deteriorated or the world catches up. >> >> And we have control over the UI/UX we provide. >> >> Have you ever thought that AngularJS is essentially a Google strategy to >> bite Javaâs market >> <http://www.quirksmode.org/blog/archives/2015/01/the_problem_wit.html>? > > > > > -- > View this message in context: http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799678p4800193.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

Jan. 18, 2015

Re: [Pharo-users] Manners on the list?

by Hilaire

Le 17/01/2015 00:48, Laura Risani a Ã©crit : > It doesn't kind of feel right saying nothing when someone gives me a > rather lengthly answer, unless it was the tacit agreement. > > So i'm facing questions whether or not to make a post, because i'm not > sure which are the right/usual manners for this particular mail-list > form of communication. > One can guess the right manner is the same manner you will use in real life: if you get help from a problem, you just say thank you. In the other hand, if you find yourself the answer to your problem, it is useful to write an answer to your problem on the mailing list: the problem you met was or will be a problem for other, so it is a nice, simple and effective way to contribute. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Jan. 18, 2015