October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Renaming "Announcement" into "Event"?

by Eliot Miranda

On Sat, Oct 8, 2011 at 2:35 AM, Hernan Wilkinson < hernan.wilkinson(a)10pines.com> wrote: > > > On Sat, Oct 8, 2011 at 6:06 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> Yes, but likely you are using leave nodes in such expressions. I don't >> think that MouseMovedAnnouncement, MouseClickedAnnouncement, >> ZeroDivideException , IndexOutOfBoundsException , or >> IllegalStateException are abstract or would have any subclasses. >> > > yes... so let me put it in another way... hmm what I'm trying to say is > that using THE class as the condition to handle an exception (i.e. as the > parameter of the on: keyword) should not be the ONLY way to express "I want > to handle this exceptional case". Doing so leads us to the necessity of > creating unnecessary exceptions hierarchies where the only reason to have an > exception subclass is to be able to handle that particular exceptional case, > and in the 90% of the cases, those classes do not define any behavior... to > name a few, the RegexError hierarchy or XMLParserException hierarchy or the > Halt hierarchy, their subclasses do not define any particular behavior > So we are telling the programmer "hey!, if you want to handle an exception, > put the exception class here", therefore any problem related to handling > exceptions will be solved based on the class and its hierarchy, we are > narrowing the options the define witch exception to handle. > On the other hand, if we say "hey! if you want to handle an exception, just > write the condition that identifies that exception here", then we are making > the options to handle exceptions "bigger" > You're reviving the entire discussion over ANSI exceptions, the Digitalk one based on classes and the instance-based on from ParcPlace. The conclusion is that the class-based system is better on balance. Classes are cheap, their names are really useful when well-chosen and being able to add behaviour to specific exceptions is a huge win. As has been pointed out, creating exception sets with #, means classes of exception can be conveniently combined. So at least for me it is better to let sleeping dogs lie and continue to enjoy class-based exceptions (and class0-based announcements). But I think the bottom line is that the declarative nature of classes is extremely useful in making a system comprehensible and navigable by the programmer. Look at how prototype-based languages end up inventing things close to classes for precisely these reasons. Anyway, I found this useful in two cases and it helps me to explain what > exceptions are really and how to avoid those big/depth exceptions > hierarchies very common in "inexperienced" programmers... and when I found I > could do something like this it blowed my head :-) > > >> On 7 October 2011 23:54, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> >> wrote: >> > yes yes, but using #, still has the coupling with the class hierarchy... >> I >> > mean, if you write: >> > [] on: Exc1, Exc2 do: [...] >> > It will handle Exc1 and it subclasses and Exc2 and its subclasses... I >> can >> > not handle just Exc1 and Exc2 >> > What I tried to say is that handling a class and its subclasses is an >> > special case of handling a collection of classes and if we can handle >> any >> > group of classes, then handling a hierarchy is just trivial, a >> particular >> > case of handling a group, then handling the hierarchy creates >> > an unnecessary coupling, maybe handy but not necessary, and showing >> > programmers that is not a RULE for the exception handling mechanism to >> > always handle a hierarchy just "break their head"... (I don't remember >> the >> > phrase for that in English :-) ) >> > >> > On Fri, Oct 7, 2011 at 3:42 PM, Lukas Renggli <renggli(a)gmail.com> >> wrote: >> >> >> >> Actually both -- Announcement and Exception -- implement #, to create >> >> such a collection: >> >> >> >> anAnnouncer >> >> on: MouseMovedAnnouncement , MouseClickedAnnouncement >> >> do: [ :ann | ... ] >> >> >> >> [ ... ] >> >> on: ZeroDivideException , IndexOutOfBoundsException , >> >> IllegalStateException >> >> do: [ :err | ... ] >> >> >> >> Lukas >> >> >> >> On 7 October 2011 20:30, Hernan Wilkinson < >> hernan.wilkinson(a)10pines.com> >> >> wrote: >> >> > >> >> > >> >> > On Fri, Oct 7, 2011 at 12:41 PM, Igor Stasenko <siguctua(a)gmail.com> >> >> > wrote: >> >> >> >> >> >> On 7 October 2011 13:53, Hernan Wilkinson >> >> >> <hernan.wilkinson(a)10pines.com> >> >> >> wrote: >> >> >> > Or remove the absurd coupling between subclassing and grouping >> >> >> > exceptions/events (or whatever name you prefer to use :-) ) that >> >> >> > leads >> >> >> > to >> >> >> > absurd/depth/big exception/events hierarchies :-) >> >> >> >> >> >> >> >> >> By proposing that, i expect that you have an alternative in mind. >> How >> >> >> else you could >> >> >> provide a grouping for exceptions/events in that case? >> >> > >> >> > yeah yeah... of course :-) ... you could create any group you want >> with >> >> > any >> >> > collection and not only groups created by a "hierarchy". >> >> > So, you could create an ExceptionToCollectionAdapter that responds to >> >> > #handles: answering true if the exception is included in the group >> you >> >> > defined. For example: >> >> > ExceptionToCollectionAdapter class>>for: aCollectionOfExceptions >> >> > ^self new initializeFor: aCollectionOfExceptions >> >> > ExceptionToCollectionAdapter>>initializeFor: aCollectionOfExcpetions >> >> > exceptions := aCollectionOfExceptions >> >> > ExceptionToCollectionAdapter>>handles: anException >> >> > ^excpetions includes: anException >> >> > Therefor now you can: >> >> > [ ... bla bla ] >> >> > on: (ExceptionToCollectionAdapter for: (Set with: exc1 with: exc2 >> >> > with: >> >> > etc)) >> >> > do: [ bla bla ] >> >> > I used a similar technique to be able to easily identify different >> >> > exceptions that are instances of the same class. >> >> > For example, I created a model to easily run preconditions and if a >> >> > precondition does not hold the exception AssertionFailed is signaled. >> >> > So, to >> >> > handle a particular assertion failure I use the name of the assertion >> in >> >> > the >> >> > #on:do:. For example. >> >> > Number>>/ aDivisor >> >> > "I removed the precondtions objects to make it easier for the >> >> > example" >> >> > aDivisor = 0 ifTrue: [ AssertionFailed signalNamed: >> >> > #divisorCanNotBeZero >> >> > ]. >> >> > bla bla >> >> > and now, to handle that assertion failure: >> >> > [ 1/0 ] >> >> > on: #divisorCanNotBeZero asExceptionToHandle >> >> > do: [ .... ] >> >> > Anyway, the magic again is the dinamic and open nature of >> smalltalk... >> >> > in >> >> > this case any object that anwers #handles: can be a parameter in the >> on: >> >> > of >> >> > the on:do:... >> >> > It is very interesiting to show this example to Java, C# programmers, >> >> > etc. >> >> > because it breaks the myth about exceptions and shows that >> exceptions >> >> > is >> >> > just another model and that in a good language you should be able to >> >> > change >> >> > it if you wanted :-)... so, GO SMALLTALK!!! :-) >> >> > >> >> > >> >> >> >> >> >> Basically, what we need is a fast way to check if given object >> belongs >> >> >> to some specific group (in case if we want to react on all >> >> >> exception/events >> >> >> in given group). >> >> >> So? >> >> >> >> >> >> >> >> >> > >> >> >> > On Thu, Oct 6, 2011 at 12:49 PM, Lukas Renggli <renggli(a)gmail.com >> > >> >> >> > wrote: >> >> >> >> >> >> >> >> On 6 October 2011 17:40, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >> >> >> > On 6 October 2011 17:24, Lukas Renggli <renggli(a)gmail.com> >> wrote: >> >> >> >> >>>> why wasting an energy on something, which not gives any >> >> >> >> >>>> benefits? >> >> >> >> >>> >> >> >> >> >>> There is a benefit when you teach Pharo and write a book. >> >> >> >> >> >> >> >> >> >> Then you should make the Exception hierarchy a subclass of >> Event >> >> >> >> >> too >> >> >> >> >> and rename all exceptions, because they are all (exceptional) >> >> >> >> >> events >> >> >> >> >> too. >> >> >> >> >> >> >> >> >> >>>> i completely agree that proper naming is important. but the >> >> >> >> >>>> framework >> >> >> >> >>>> was originally designed not by us, >> >> >> >> >>>> and i think its not quite correct to rename it without >> asking >> >> >> >> >>>> the >> >> >> >> >>>> author. >> >> >> >> >>> >> >> >> >> >>> This is what this email is about :-) >> >> >> >> >> >> >> >> >> >> Puns aside: Why not just remove the Announcement class >> >> >> >> >> altogether? >> >> >> >> >> It >> >> >> >> >> used to be empty in the original implementation and serves no >> >> >> >> >> real >> >> >> >> >> purpose other than grouping its subclasses. Any object can >> >> >> >> >> potentially >> >> >> >> >> represent an event. >> >> >> >> >> >> >> >> >> > err.. an Announcement playing own role as a root class for all >> >> >> >> > announcements. >> >> >> >> > In same way as Exception is a root of all exceptions, so if you >> >> >> >> > want >> >> >> >> > to handle all exceptions you putting Exception class. >> >> >> >> > If you remove the notion of root, then you will need to >> introduce >> >> >> >> > something else in order to satisfy 'i wanna handle all >> >> >> >> > exceptions/events , >> >> >> >> > no matter what they are'. >> >> >> >> >> >> >> >> Object would be your choice for all events then. >> >> >> >> >> >> >> >> Lukas >> >> >> >> >> >> >> >> -- >> >> >> >> Lukas Renggli >> >> >> >> www.lukas-renggli.ch >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > HernÃ¡n Wilkinson >> >> >> > Agile Software Development, Teaching & Coaching >> >> >> > Mobile: +54 - 911 - 4470 - 7207 >> >> >> > email: hernan.wilkinson(a)10Pines.com >> >> >> > site: http://www.10Pines.com >> >> >> > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Best regards, >> >> >> Igor Stasenko. >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > HernÃ¡n Wilkinson >> >> > Agile Software Development, Teaching & Coaching >> >> > Mobile: +54 - 911 - 4470 - 7207 >> >> > email: hernan.wilkinson(a)10Pines.com >> >> > site: http://www.10Pines.com >> >> > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >> >> > >> >> >> >> >> >> >> >> -- >> >> Lukas Renggli >> >> www.lukas-renggli.ch >> >> >> > >> > >> > >> > -- >> > HernÃ¡n Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: hernan.wilkinson(a)10Pines.com >> > site: http://www.10Pines.com >> > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina > > -- best, Eliot

Oct. 8, 2011

Re: [Pharo-project] [squeak-dev] Re: Too many semaphores, image blocked

by David T. Lewis

For an immediate workaround, you can probably just open the image with an interpreter VM, change the parameter, save and restart on Cog. Dave On Fri, Oct 07, 2011 at 02:43:16PM -0700, Eliot Miranda wrote: > On Fri, Oct 7, 2011 at 2:31 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > > > Eliot, > > > > Is there a way to save the image given that it is non-responsive? > > Otherwise (and this could be "how it is") one would have to apply the fix > > before having the problem. Just curious. Should we all periodically take a > > semaphore head count in our images? > > > > I try to leave a reasonable trail of backups of working images just in case > > I do something stupid; a little uncertainty can motivate cautious > > behavior... > > > > Hmm... I think what's needed is a command-line parameter. Give me a few... > > > > Bill > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Eliot Miranda [ > > eliot.miranda(a)gmail.com] > > Sent: Friday, October 07, 2011 4:22 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] Too many semaphores, image blocked > > > > Hi Janko, > > > > you need to /save/ the image having applied Smalltalk vm > > maxExternalSemaphoresSilently: 3000. This must be set in the image at > > start-up, not after the image has loaded. i.e. the VM inspects the value > > saved in the image header and applies the value *before* the image starts > > running. > > > > 2011/10/7 Janko Miv??ek <janko.mivsek(a)eranova.si<mailto: > > janko.mivsek(a)eranova.si>> > > Hi Henrik, > > > > S, Henrik Sperre Johansen pi??e: > > > On 05.10.2011 01:18, Schwab,Wilhelm K wrote: > > > > >> The log you posted contains the string "Not enough space for external > > >> objects, set a larger size at startup!" Maybe a command-line switch > > >> to the vm will give you more memory and a way to get the image going? > > > > > Smalltalk vm maxExternalSemaphoresSilently: aSize would be the line to > > > include. > > > If the script passed on a command line is higher in the startuplist than > > > the InputEventSensor, it would get it working again. > > > > Ok, I'm back having time to look at this problem and I made a start.st< > > http://start.st> > > script below, start the image with it, but get the same blank screen as > > you can see in attached screenshot. Ctrl or Alt . doesn't help. > > > > start.st<http://start.st> > > Smalltalk vm maxExternalSemaphoresSilently: 3000 > > > > > > ./Contents/Linux/squeak ./Contents/Resources/waste.image start.st< > > http://start.st> > > > > Any more idea? Otherwise I'll start to recover from changes, but > > starting this nonresponsive image would of course be faster solution:) > > > > Best regards > > Janko > > > > > > -- > > Janko Miv??ek > > Aida/Web > > Smalltalk Web Application Server > > http://www.aidaweb.si > > > > > > > > -- > > best, > > Eliot > > > > > > > > > -- > best, > Eliot >

Oct. 8, 2011

Re: [Pharo-project] TimeZoneDatabase port to Pharo

by David T. Lewis

On Fri, Oct 07, 2011 at 10:42:08AM -0700, Paul DeBruicker wrote: > Hi Dave, > > I've gotten your TimeZoneDatabase package to load into Pharo. It passes > all tests on Linux. I've attached the Monticello package to this email. > > I'm not sure what else I should check to see if its working properly. > If you let me know I'll give it a go. Paul, Excellent, thank you very much. After loading your update, all tests are green on Squeak trunk also. I am assuming your changes are MIT, so I copied your MCZ to www.squeaksource.com/TimeZoneDatabase and also added you as developer on the project. CC to the lists. Much appreciated, Dave

Oct. 8, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by StÃ©phane Ducasse

On Oct 8, 2011, at 5:56 PM, Janko MivÅ¡ek wrote: > Hi guys, > > We are starting to use Fuel to exchange data daily, but without exactly > the same version of Fuel loaded, exported data is just too frequently > not importable anymore. And exception report is meaningless, you can > only guess that Fuel version is to blame. > > So, it is more that a time to: > > - stabilize and freeze the file format > - put a version info into a file and check it while importing there is one already. > - meaningful error reporting in such cases > > This is IMHO more than necessary for Fuel to become a production ready > serializer and I'd say Fuel is now "old enough" to become such :) Yes. Now what I would love is that even if fuel changes that the evolution of information is taken into account because like that it will be exercised for real. > > Best regards > Janko > > > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 >

Oct. 8, 2011

[Pharo-project] When will Fuel file format stabilize?

by Janko MivÅ¡ek

Hi guys, We are starting to use Fuel to exchange data daily, but without exactly the same version of Fuel loaded, exported data is just too frequently not importable anymore. And exception report is meaningless, you can only guess that Fuel version is to blame. So, it is more that a time to: - stabilize and freeze the file format - put a version info into a file and check it while importing - meaningful error reporting in such cases This is IMHO more than necessary for Fuel to become a production ready serializer and I'd say Fuel is now "old enough" to become such :) Best regards Janko -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Oct. 8, 2011

[Pharo-project] [update 1.4] #14189

by StÃ©phane Ducasse

14189 ----- - Issue 4903: New version of Zinc - Added a version of deprecated: in Object

Oct. 8, 2011

[Pharo-project] [update 1.4] #14188

by StÃ©phane Ducasse

14188 ----- - Issue 4900: CompiledMethod printString. Fixing Array >> #printOn:. http://code.google.com/p/pharo/issues/detail?id=4900 - Issue 4896: Small cleanup in PlugabbleListMorph. Thanks Benjamin van Ryseghem. Indeed there is no useless simple fixes. http://code.google.com/p/pharo/issues/detail?id=4896 - Issue 4895: Update of AbstractTool. Thanks Benjamin van Ryseghem. http://code.google.com/p/pharo/issues/detail?id=4895 - Issue Issue 4898: Fix/Improve the drag and drop on PluggableListMorph http://code.google.com/p/pharo/issues/detail?id=4898 I'm back :) Stef

Oct. 8, 2011

[Pharo-project] Destruction of object in Pharo/Smalltalk - When I clean resources?

by nullPointer

I have a complexe object with many internally events references. I want know what is the best place where I have put the code for clean that resources when the object is cleaned for Garbage collector. I have fear that references never out, and still throwing notifiers. Regards, and thanks for the help. -- View this message in context: http://forum.world.st/Destruction-of-object-in-Pharo-Smalltalk-When-I-clean… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 8, 2011

Re: [Pharo-project] Renaming "Announcement" into "Event"?

by Hernan Wilkinson

On Sat, Oct 8, 2011 at 6:06 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > Yes, but likely you are using leave nodes in such expressions. I don't > think that MouseMovedAnnouncement, MouseClickedAnnouncement, > ZeroDivideException , IndexOutOfBoundsException , or > IllegalStateException are abstract or would have any subclasses. > yes... so let me put it in another way... hmm what I'm trying to say is that using THE class as the condition to handle an exception (i.e. as the parameter of the on: keyword) should not be the ONLY way to express "I want to handle this exceptional case". Doing so leads us to the necessity of creating unnecessary exceptions hierarchies where the only reason to have an exception subclass is to be able to handle that particular exceptional case, and in the 90% of the cases, those classes do not define any behavior... to name a few, the RegexError hierarchy or XMLParserException hierarchy or the Halt hierarchy, their subclasses do not define any particular behavior So we are telling the programmer "hey!, if you want to handle an exception, put the exception class here", therefore any problem related to handling exceptions will be solved based on the class and its hierarchy, we are narrowing the options the define witch exception to handle. On the other hand, if we say "hey! if you want to handle an exception, just write the condition that identifies that exception here", then we are making the options to handle exceptions "bigger" Anyway, I found this useful in two cases and it helps me to explain what exceptions are really and how to avoid those big/depth exceptions hierarchies very common in "inexperienced" programmers... and when I found I could do something like this it blowed my head :-) > On 7 October 2011 23:54, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> > wrote: > > yes yes, but using #, still has the coupling with the class hierarchy... > I > > mean, if you write: > > [] on: Exc1, Exc2 do: [...] > > It will handle Exc1 and it subclasses and Exc2 and its subclasses... I > can > > not handle just Exc1 and Exc2 > > What I tried to say is that handling a class and its subclasses is an > > special case of handling a collection of classes and if we can handle any > > group of classes, then handling a hierarchy is just trivial, a particular > > case of handling a group, then handling the hierarchy creates > > an unnecessary coupling, maybe handy but not necessary, and showing > > programmers that is not a RULE for the exception handling mechanism to > > always handle a hierarchy just "break their head"... (I don't remember > the > > phrase for that in English :-) ) > > > > On Fri, Oct 7, 2011 at 3:42 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> > >> Actually both -- Announcement and Exception -- implement #, to create > >> such a collection: > >> > >> anAnnouncer > >> on: MouseMovedAnnouncement , MouseClickedAnnouncement > >> do: [ :ann | ... ] > >> > >> [ ... ] > >> on: ZeroDivideException , IndexOutOfBoundsException , > >> IllegalStateException > >> do: [ :err | ... ] > >> > >> Lukas > >> > >> On 7 October 2011 20:30, Hernan Wilkinson <hernan.wilkinson(a)10pines.com > > > >> wrote: > >> > > >> > > >> > On Fri, Oct 7, 2011 at 12:41 PM, Igor Stasenko <siguctua(a)gmail.com> > >> > wrote: > >> >> > >> >> On 7 October 2011 13:53, Hernan Wilkinson > >> >> <hernan.wilkinson(a)10pines.com> > >> >> wrote: > >> >> > Or remove the absurd coupling between subclassing and grouping > >> >> > exceptions/events (or whatever name you prefer to use :-) ) that > >> >> > leads > >> >> > to > >> >> > absurd/depth/big exception/events hierarchies :-) > >> >> > >> >> > >> >> By proposing that, i expect that you have an alternative in mind. How > >> >> else you could > >> >> provide a grouping for exceptions/events in that case? > >> > > >> > yeah yeah... of course :-) ... you could create any group you want > with > >> > any > >> > collection and not only groups created by a "hierarchy". > >> > So, you could create an ExceptionToCollectionAdapter that responds to > >> > #handles: answering true if the exception is included in the group you > >> > defined. For example: > >> > ExceptionToCollectionAdapter class>>for: aCollectionOfExceptions > >> > ^self new initializeFor: aCollectionOfExceptions > >> > ExceptionToCollectionAdapter>>initializeFor: aCollectionOfExcpetions > >> > exceptions := aCollectionOfExceptions > >> > ExceptionToCollectionAdapter>>handles: anException > >> > ^excpetions includes: anException > >> > Therefor now you can: > >> > [ ... bla bla ] > >> > on: (ExceptionToCollectionAdapter for: (Set with: exc1 with: exc2 > >> > with: > >> > etc)) > >> > do: [ bla bla ] > >> > I used a similar technique to be able to easily identify different > >> > exceptions that are instances of the same class. > >> > For example, I created a model to easily run preconditions and if a > >> > precondition does not hold the exception AssertionFailed is signaled. > >> > So, to > >> > handle a particular assertion failure I use the name of the assertion > in > >> > the > >> > #on:do:. For example. > >> > Number>>/ aDivisor > >> > "I removed the precondtions objects to make it easier for the > >> > example" > >> > aDivisor = 0 ifTrue: [ AssertionFailed signalNamed: > >> > #divisorCanNotBeZero > >> > ]. > >> > bla bla > >> > and now, to handle that assertion failure: > >> > [ 1/0 ] > >> > on: #divisorCanNotBeZero asExceptionToHandle > >> > do: [ .... ] > >> > Anyway, the magic again is the dinamic and open nature of smalltalk... > >> > in > >> > this case any object that anwers #handles: can be a parameter in the > on: > >> > of > >> > the on:do:... > >> > It is very interesiting to show this example to Java, C# programmers, > >> > etc. > >> > because it breaks the myth about exceptions and shows that exceptions > >> > is > >> > just another model and that in a good language you should be able to > >> > change > >> > it if you wanted :-)... so, GO SMALLTALK!!! :-) > >> > > >> > > >> >> > >> >> Basically, what we need is a fast way to check if given object > belongs > >> >> to some specific group (in case if we want to react on all > >> >> exception/events > >> >> in given group). > >> >> So? > >> >> > >> >> > >> >> > > >> >> > On Thu, Oct 6, 2011 at 12:49 PM, Lukas Renggli <renggli(a)gmail.com> > >> >> > wrote: > >> >> >> > >> >> >> On 6 October 2011 17:40, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> >> >> > On 6 October 2011 17:24, Lukas Renggli <renggli(a)gmail.com> > wrote: > >> >> >> >>>> why wasting an energy on something, which not gives any > >> >> >> >>>> benefits? > >> >> >> >>> > >> >> >> >>> There is a benefit when you teach Pharo and write a book. > >> >> >> >> > >> >> >> >> Then you should make the Exception hierarchy a subclass of > Event > >> >> >> >> too > >> >> >> >> and rename all exceptions, because they are all (exceptional) > >> >> >> >> events > >> >> >> >> too. > >> >> >> >> > >> >> >> >>>> i completely agree that proper naming is important. but the > >> >> >> >>>> framework > >> >> >> >>>> was originally designed not by us, > >> >> >> >>>> and i think its not quite correct to rename it without asking > >> >> >> >>>> the > >> >> >> >>>> author. > >> >> >> >>> > >> >> >> >>> This is what this email is about :-) > >> >> >> >> > >> >> >> >> Puns aside: Why not just remove the Announcement class > >> >> >> >> altogether? > >> >> >> >> It > >> >> >> >> used to be empty in the original implementation and serves no > >> >> >> >> real > >> >> >> >> purpose other than grouping its subclasses. Any object can > >> >> >> >> potentially > >> >> >> >> represent an event. > >> >> >> >> > >> >> >> > err.. an Announcement playing own role as a root class for all > >> >> >> > announcements. > >> >> >> > In same way as Exception is a root of all exceptions, so if you > >> >> >> > want > >> >> >> > to handle all exceptions you putting Exception class. > >> >> >> > If you remove the notion of root, then you will need to > introduce > >> >> >> > something else in order to satisfy 'i wanna handle all > >> >> >> > exceptions/events , > >> >> >> > no matter what they are'. > >> >> >> > >> >> >> Object would be your choice for all events then. > >> >> >> > >> >> >> Lukas > >> >> >> > >> >> >> -- > >> >> >> Lukas Renggli > >> >> >> www.lukas-renggli.ch > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > HernÃ¡n Wilkinson > >> >> > Agile Software Development, Teaching & Coaching > >> >> > Mobile: +54 - 911 - 4470 - 7207 > >> >> > email: hernan.wilkinson(a)10Pines.com > >> >> > site: http://www.10Pines.com > >> >> > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Best regards, > >> >> Igor Stasenko. > >> >> > >> > > >> > > >> > > >> > -- > >> > HernÃ¡n Wilkinson > >> > Agile Software Development, Teaching & Coaching > >> > Mobile: +54 - 911 - 4470 - 7207 > >> > email: hernan.wilkinson(a)10Pines.com > >> > site: http://www.10Pines.com > >> > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina > >> > > >> > >> > >> > >> -- > >> Lukas Renggli > >> www.lukas-renggli.ch > >> > > > > > > > > -- > > HernÃ¡n Wilkinson > > Agile Software Development, Teaching & Coaching > > Mobile: +54 - 911 - 4470 - 7207 > > email: hernan.wilkinson(a)10Pines.com > > site: http://www.10Pines.com > > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Oct. 8, 2011

Re: [Pharo-project] Renaming "Announcement" into "Event"?

by Lukas Renggli

Yes, but likely you are using leave nodes in such expressions. I don't think that MouseMovedAnnouncement, MouseClickedAnnouncement, ZeroDivideException , IndexOutOfBoundsException , or IllegalStateException are abstract or would have any subclasses. On 7 October 2011 23:54, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> wrote: > yes yes, but using #, still has the coupling with the class hierarchy... I > mean, if you write: > [] on: Exc1, Â Exc2 do: [...] > It will handle Exc1 and it subclasses and Exc2 and its subclasses... I can > not handle just Exc1 and Exc2 > What I tried to say is that handling a class and its subclasses is an > special case of handling a collection of classes and if we can handle any > group of classes, then handling a hierarchy is just trivial, a particular > case of handling a group, then handling the hierarchy creates > anÂ unnecessaryÂ coupling, maybe handy but notÂ necessary, and showing > programmers that is not a RULE for the exception handling mechanism to > always handle a hierarchy just "break their head"... (I don't remember the > phrase for that in English :-) ) > > On Fri, Oct 7, 2011 at 3:42 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> Actually both -- Announcement and Exception -- implement #, to create >> such a collection: >> >> Â Â anAnnouncer >> Â Â Â on: MouseMovedAnnouncement , MouseClickedAnnouncement >> Â Â Â do: [ :ann | ... ] >> >> Â Â [ ... ] >> Â Â Â on: ZeroDivideException , IndexOutOfBoundsException , >> IllegalStateException >> Â Â Â do: [ :err | ... ] >> >> Lukas >> >> On 7 October 2011 20:30, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> >> wrote: >> > >> > >> > On Fri, Oct 7, 2011 at 12:41 PM, Igor Stasenko <siguctua(a)gmail.com> >> > wrote: >> >> >> >> On 7 October 2011 13:53, Hernan Wilkinson >> >> <hernan.wilkinson(a)10pines.com> >> >> wrote: >> >> > Or remove the absurd coupling between subclassing and grouping >> >> > exceptions/events (or whatever name you prefer to use :-) ) that >> >> > leads >> >> > to >> >> > absurd/depth/big exception/events hierarchies :-) >> >> >> >> >> >> By proposing that, i expect that you have an alternative in mind. How >> >> else you could >> >> provide a grouping for exceptions/events in that case? >> > >> > yeah yeah... of course :-) ... you could create any group you want with >> > any >> > collection and not only groups created by a "hierarchy". >> > So, you could create an ExceptionToCollectionAdapter that responds to >> > #handles: answering true if the exception is included in the group you >> > defined. For example: >> > ExceptionToCollectionAdapter class>>for: aCollectionOfExceptions >> > ^self new initializeFor: aCollectionOfExceptions >> > ExceptionToCollectionAdapter>>initializeFor: aCollectionOfExcpetions >> > exceptions := aCollectionOfExceptions >> > ExceptionToCollectionAdapter>>handles: anException >> > ^excpetions includes: anException >> > Therefor now you can: >> > [ ... bla bla ] >> > Â on: (ExceptionToCollectionAdapter for: (Set with: exc1 with: exc2 >> > with: >> > etc)) >> > Â do: [ bla bla ] >> > I used a similar technique to be able to easily identify different >> > exceptions that are instances of the same class. >> > For example, I created a model to easily run preconditions and if a >> > precondition does not hold the exception AssertionFailed is signaled. >> > So, to >> > handle a particular assertion failure I use the name of the assertion in >> > the >> > #on:do:. For example. >> > Number>>/ aDivisor >> > Â Â "I removed the precondtions objects to make it easier for the >> > example" >> > Â Â aDivisor = 0 ifTrue: [ AssertionFailed signalNamed: >> > #divisorCanNotBeZero >> > ]. >> > Â Â bla bla >> > and now, to handle that assertion failure: >> > [ 1/0 ] >> > Â on: #divisorCanNotBeZero asExceptionToHandle >> > Â do: [ .... ] >> > Anyway, the magic again is the dinamic and open nature of smalltalk... >> > in >> > this case any object that anwers #handles: can be a parameter in the on: >> > of >> > the on:do:... >> > It is very interesiting to show this example to Java, C# programmers, >> > etc. >> > Â because it breaks the myth about exceptions and shows that exceptions >> > is >> > just another model and that in a good language you should be able to >> > change >> > it if you wanted :-)... so, GO SMALLTALK!!! :-) >> > >> > >> >> >> >> Basically, what we need is a fast way to check if given object belongs >> >> to some specific group (in case if we want to react on all >> >> exception/events >> >> in given group). >> >> So? >> >> >> >> >> >> > >> >> > On Thu, Oct 6, 2011 at 12:49 PM, Lukas Renggli <renggli(a)gmail.com> >> >> > wrote: >> >> >> >> >> >> On 6 October 2011 17:40, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> > On 6 October 2011 17:24, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> >> >>>> why wasting an energy on something, which not gives any >> >> >> >>>> benefits? >> >> >> >>> >> >> >> >>> There is a benefit when you teach Pharo and write a book. >> >> >> >> >> >> >> >> Then you should make the Exception hierarchy a subclass of Event >> >> >> >> too >> >> >> >> and rename all exceptions, because they are all (exceptional) >> >> >> >> events >> >> >> >> too. >> >> >> >> >> >> >> >>>> i completely agree that proper naming is important. but the >> >> >> >>>> framework >> >> >> >>>> was originally designed not by us, >> >> >> >>>> and i think its not quite correct to rename it without asking >> >> >> >>>> the >> >> >> >>>> author. >> >> >> >>> >> >> >> >>> This is what this email is about :-) >> >> >> >> >> >> >> >> Puns aside: Why not just remove the Announcement class >> >> >> >> altogether? >> >> >> >> It >> >> >> >> used to be empty in the original implementation and serves no >> >> >> >> real >> >> >> >> purpose other than grouping its subclasses. Any object can >> >> >> >> potentially >> >> >> >> represent an event. >> >> >> >> >> >> >> > err.. an Announcement playing own role as a root class for all >> >> >> > announcements. >> >> >> > In same way as Exception is a root of all exceptions, so if you >> >> >> > want >> >> >> > to handle all exceptions you putting Exception class. >> >> >> > If you remove the notion of root, then you will need to introduce >> >> >> > something else in order to satisfy 'i wanna handle all >> >> >> > exceptions/events , >> >> >> > no matter what they are'. >> >> >> >> >> >> Object would be your choice for all events then. >> >> >> >> >> >> Lukas >> >> >> >> >> >> -- >> >> >> Lukas Renggli >> >> >> www.lukas-renggli.ch >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > HernÃ¡n Wilkinson >> >> > Agile Software Development, Teaching & Coaching >> >> > Mobile: +54 - 911 - 4470 - 7207 >> >> > email: hernan.wilkinson(a)10Pines.com >> >> > site:Â http://www.10Pines.com >> >> > Address: ParaguayÂ 523, Floor 7 N, Buenos Aires, Argentina >> >> > >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> > >> > >> > >> > -- >> > HernÃ¡n Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: hernan.wilkinson(a)10Pines.com >> > site:Â http://www.10Pines.com >> > Address: ParaguayÂ 523, Floor 7 N, Buenos Aires, Argentina >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site:Â http://www.10Pines.com > Address: ParaguayÂ 523, Floor 7 N, Buenos Aires, Argentina > -- Lukas Renggli www.lukas-renggli.ch

Oct. 8, 2011