Actually this is even part of ANSI. Any Smalltalk that does not support this out of the box is not ANSI compatible :-)
Lukas On 7 October 2011 20:42, Lukas Renggli <[email protected]> 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 <[email protected]> > wrote: >> >> >> On Fri, Oct 7, 2011 at 12:41 PM, Igor Stasenko <[email protected]> wrote: >>> >>> On 7 October 2011 13:53, Hernan Wilkinson <[email protected]> >>> 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 <[email protected]> >>> > wrote: >>> >> >>> >> On 6 October 2011 17:40, Igor Stasenko <[email protected]> wrote: >>> >> > On 6 October 2011 17:24, Lukas Renggli <[email protected]> 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: [email protected] >>> > 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: [email protected] >> site: http://www.10Pines.com >> Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch
