On 3 January 2012 14:20, Lukas Renggli <[email protected]> wrote: >>>> If everybody has its own version then we do not improve the infrastructure. >>> >>> Performance issues aside, the current implementation forces me to use >>> a different implementation because Pharo's announcements have a >>> different implementation of selecting the handler (point 7). However, >>> the really weird thing is that Pharo's announcements are now suddenly >>> inconsistent with the Pharo exceptions and how they select the >>> handler. Do you think this is better or worse? >>> >> you lost me here. why announcements have to be consistent with >> exceptions? something which is completely >> orthogonal to them? > > Exceptions and Announcements used to implement a very similar > protocol: see their implementation of X class>>#handles:, X>>on:do:, > XSet>>#handles:, XSet>>#, etc. > as well as it could serve as a source of confusion, because you using same protocol for different purposes in two different frameworks. A medal always has two sides :)
> Consistency makes frameworks easy to understand and use. > >> it is like saying that apples are inconsistent with oranges. > > - Apples and oranges are inconsistent the way they are eaten (oranges > have to be piled first and come in slices). > > - Apples and pears are consistent the way they are eaten (even if they > taste very different). > > If that is too abstract replace > > Apples => Announcements > Oranges => change:/update: > Pears => Exceptions > your analogy having a small glitch: all those objects sharing common property - they can be eaten. now in smalltalk you can do anything, any object can be 'eaten'. but it doesn't means that they should, otherwise we're just put all behavior in Object class, and use subclasses as a dumb state holders (color, taste, hasToBePiled etc) Exceptions are conceptually different from Announcements in a way they should be used and handled, and i don't see a great value of having synergy between them. If we keep driving analogies, i think a more precise would be to tell that exceptions are to be 'eaten' and announcements are to be 'heard'. And in that way there is no consistency at all. Actually a logic with using inheritance chain to determine whether announcement should be delivered to subscription or not is IMO a major flaw, borrowed from Exceptions. Because testing a class membership is an expensive operation and if you are so concerned about performance, this is a first thing which you would be likely remove. > Lukas > > > >> >> aside of that, i added the changeset, so you can now choose whether >> your announcement subscription is handling >> announcement or not based on announcement object itself, not its class. >> see http://code.google.com/p/pharo/issues/detail?id=5145 >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Best regards, Igor Stasenko.
