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 <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina
