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@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@10pines.com> wrote:
On Fri, Oct 7, 2011 at 12:41 PM, Igor Stasenko <siguctua@gmail.com>
wrote:
On 7 October 2011 13:53, Hernan Wilkinson <hernan.wilkinson@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@gmail.com> wrote:
On 6 October 2011 17:40, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 October 2011 17:24, Lukas Renggli <renggli@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@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@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@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina