[Pharo-project] Renaming "Announcement" into "Event"?
Hi! What about moving our rebelness and energy into innovation rather than giving strange name? :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I dont agree entirely with you Alex, nowadays we announce an announcement, instead of sending events. I mean, should we start announcing events? Fernando On Thu, Oct 6, 2011 at 3:15 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
What about moving our rebelness and energy into innovation rather than giving strange name? :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
What the whole world call "event" we call "announcement". I understand the need for a new name back at the time where Smalltalk has its old event mechanism. But this does not hold anymore I feel. I though about this renaming when working on Pharo by example 2. Having "Event" instead of "Announcement" in the index tells much more what the chapter is about. Alexandre On 6 Oct 2011, at 10:58, Fernando Olivero wrote:
I dont agree entirely with you Alex, nowadays we announce an announcement, instead of sending events. I mean, should we start announcing events? Fernando
On Thu, Oct 6, 2011 at 3:15 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
What about moving our rebelness and energy into innovation rather than giving strange name? :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
why wasting an energy on something, which not gives any benefits? 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. On 6 October 2011 16:21, Alexandre Bergel <alexandre.bergel@me.com> wrote:
What the whole world call "event" we call "announcement". I understand the need for a new name back at the time where Smalltalk has its old event mechanism. But this does not hold anymore I feel.
I though about this renaming when working on Pharo by example 2. Having "Event" instead of "Announcement" in the index tells much more what the chapter is about.
Alexandre
On 6 Oct 2011, at 10:58, Fernando Olivero wrote:
I dont agree entirely with you Alex, nowadays we announce an announcement, instead of sending events. I mean, should we start announcing events? Fernando
On Thu, Oct 6, 2011 at 3:15 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
What about moving our rebelness and energy into innovation rather than giving strange name? :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Best regards, Igor Stasenko.
why wasting an energy on something, which not gives any benefits?
There is a benefit when you teach Pharo and write a book.
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 :-) Alexandre
On 6 October 2011 16:21, Alexandre Bergel <alexandre.bergel@me.com> wrote:
What the whole world call "event" we call "announcement". I understand the need for a new name back at the time where Smalltalk has its old event mechanism. But this does not hold anymore I feel.
I though about this renaming when working on Pharo by example 2. Having "Event" instead of "Announcement" in the index tells much more what the chapter is about.
Alexandre
On 6 Oct 2011, at 10:58, Fernando Olivero wrote:
I dont agree entirely with you Alex, nowadays we announce an announcement, instead of sending events. I mean, should we start announcing events? Fernando
On Thu, Oct 6, 2011 at 3:15 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
What about moving our rebelness and energy into innovation rather than giving strange name? :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Best regards, Igor Stasenko.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 6 October 2011 17:03, Alexandre Bergel <alexandre.bergel@me.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.
I don't see it. You can always say in introduction that Announcements is an event(s) framework.
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 :-)
Alexandre
On 6 October 2011 16:21, Alexandre Bergel <alexandre.bergel@me.com> wrote:
What the whole world call "event" we call "announcement". I understand the need for a new name back at the time where Smalltalk has its old event mechanism. But this does not hold anymore I feel.
I though about this renaming when working on Pharo by example 2. Having "Event" instead of "Announcement" in the index tells much more what the chapter is about.
Alexandre
On 6 Oct 2011, at 10:58, Fernando Olivero wrote:
I dont agree entirely with you Alex, nowadays we announce an announcement, instead of sending events. I mean, should we start announcing events? Fernando
On Thu, Oct 6, 2011 at 3:15 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
What about moving our rebelness and energy into innovation rather than giving strange name? :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Best regards, Igor Stasenko.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Best regards, Igor Stasenko.
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. Lukas -- Lukas Renggli www.lukas-renggli.ch
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'.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Best regards, Igor Stasenko.
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
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 :-) 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 <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina
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? 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.
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 <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina
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
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 <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
-- Lukas Renggli www.lukas-renggli.ch
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
Yes, but likely you are using leave nodes in such expressions. I don't think that MouseMovedAnnouncement, MouseClickedAnnouncement, ZeroDivideException , IndexOutOfBoundsException , or IllegalStateException are abstract or would have any subclasses. On 7 October 2011 23:54, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
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 Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina
-- Lukas Renggli www.lukas-renggli.ch
On Sat, Oct 8, 2011 at 6:06 AM, Lukas Renggli <renggli@gmail.com> wrote:
Yes, but likely you are using leave nodes in such expressions. I don't think that MouseMovedAnnouncement, MouseClickedAnnouncement, ZeroDivideException , IndexOutOfBoundsException , or IllegalStateException are abstract or would have any subclasses.
yes... so let me put it in another way... hmm what I'm trying to say is that using THE class as the condition to handle an exception (i.e. as the parameter of the on: keyword) should not be the ONLY way to express "I want to handle this exceptional case". Doing so leads us to the necessity of creating unnecessary exceptions hierarchies where the only reason to have an exception subclass is to be able to handle that particular exceptional case, and in the 90% of the cases, those classes do not define any behavior... to name a few, the RegexError hierarchy or XMLParserException hierarchy or the Halt hierarchy, their subclasses do not define any particular behavior So we are telling the programmer "hey!, if you want to handle an exception, put the exception class here", therefore any problem related to handling exceptions will be solved based on the class and its hierarchy, we are narrowing the options the define witch exception to handle. On the other hand, if we say "hey! if you want to handle an exception, just write the condition that identifies that exception here", then we are making the options to handle exceptions "bigger" Anyway, I found this useful in two cases and it helps me to explain what exceptions are really and how to avoid those big/depth exceptions hierarchies very common in "inexperienced" programmers... and when I found I could do something like this it blowed my head :-)
On 7 October 2011 23:54, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
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 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
On Sat, Oct 8, 2011 at 2:35 AM, Hernan Wilkinson < hernan.wilkinson@10pines.com> wrote:
On Sat, Oct 8, 2011 at 6:06 AM, Lukas Renggli <renggli@gmail.com> wrote:
Yes, but likely you are using leave nodes in such expressions. I don't think that MouseMovedAnnouncement, MouseClickedAnnouncement, ZeroDivideException , IndexOutOfBoundsException , or IllegalStateException are abstract or would have any subclasses.
yes... so let me put it in another way... hmm what I'm trying to say is that using THE class as the condition to handle an exception (i.e. as the parameter of the on: keyword) should not be the ONLY way to express "I want to handle this exceptional case". Doing so leads us to the necessity of creating unnecessary exceptions hierarchies where the only reason to have an exception subclass is to be able to handle that particular exceptional case, and in the 90% of the cases, those classes do not define any behavior... to name a few, the RegexError hierarchy or XMLParserException hierarchy or the Halt hierarchy, their subclasses do not define any particular behavior So we are telling the programmer "hey!, if you want to handle an exception, put the exception class here", therefore any problem related to handling exceptions will be solved based on the class and its hierarchy, we are narrowing the options the define witch exception to handle. On the other hand, if we say "hey! if you want to handle an exception, just write the condition that identifies that exception here", then we are making the options to handle exceptions "bigger"
You're reviving the entire discussion over ANSI exceptions, the Digitalk one based on classes and the instance-based on from ParcPlace. The conclusion is that the class-based system is better on balance. Classes are cheap, their names are really useful when well-chosen and being able to add behaviour to specific exceptions is a huge win. As has been pointed out, creating exception sets with #, means classes of exception can be conveniently combined. So at least for me it is better to let sleeping dogs lie and continue to enjoy class-based exceptions (and class0-based announcements). But I think the bottom line is that the declarative nature of classes is extremely useful in making a system comprehensible and navigable by the programmer. Look at how prototype-based languages end up inventing things close to classes for precisely these reasons. Anyway, I found this useful in two cases and it helps me to explain what
exceptions are really and how to avoid those big/depth exceptions hierarchies very common in "inexperienced" programmers... and when I found I could do something like this it blowed my head :-)
On 7 October 2011 23:54, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
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 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
-- best, Eliot
Hi Eliot! On Sat, Oct 8, 2011 at 3:00 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
You're reviving the entire discussion over ANSI exceptions, the Digitalk one based on classes and the instance-based on from ParcPlace.
Not exactly... I was only suggesting that is not good to couple class hierarchy with exception handling...
The conclusion is that the class-based system is better on balance.
I agree with that... I have used the VA exception based on ExceptionalEvent and Signal and as you say, I prefer to have classes to model exceptions Classes are cheap, their names are really useful when well-chosen and being
able to add behaviour to specific exceptions is a huge win.
Yes, agree
As has been pointed out, creating exception sets with #, means classes of exception can be conveniently combined. So at least for me it is better to let sleeping dogs lie and continue to enjoy class-based exceptions (and class0-based announcements).
I agree, again, I was trying to say that selecting a exception handler should not be only close to a class and its subclasses, and I showed in a previous example how that is supported currently in Pharo, which I think it is great. Well, I hope I made myself clear :-) Bye! Hernan.
But I think the bottom line is that the declarative nature of classes is extremely useful in making a system comprehensible and navigable by the programmer. Look at how prototype-based languages end up inventing things close to classes for precisely these reasons.
Anyway, I found this useful in two cases and it helps me to explain what
exceptions are really and how to avoid those big/depth exceptions hierarchies very common in "inexperienced" programmers... and when I found I could do something like this it blowed my head :-)
On 7 October 2011 23:54, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
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 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
-- best, Eliot
-- *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
Hello, I always use Event suffix for my application Announcement subclasses 2011/10/6 Alexandre Bergel <alexandre.bergel@me.com>
Hi!
What about moving our rebelness and energy into innovation rather than giving strange name? :-)
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (7)
-
Alexandre Bergel -
Denis Kudriashov -
Eliot Miranda -
Fernando Olivero -
Hernan Wilkinson -
Igor Stasenko -
Lukas Renggli