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

Lukas Renggli renggli at gmail.com
Fri Oct 7 14:42:35 EDT 2011


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



-- 
Lukas Renggli
www.lukas-renggli.ch




More information about the Pharo-dev mailing list