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 <[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 > > -- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [email protected] site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina
