2009/11/2 Alain Plantec <alain.plantec@free.fr>:
Igor Stasenko wrote:
2009/11/1 Tudor Girba <tudor.girba@gmail.com>:
Indeed, the main and only goal of Announcement is to provide an object- oriented (Exception-like) way to handle notifications.
I have used the Announcements implementation of Lukas on several occasions and I did not feel the need for anything else.
You indeed should subclass Announcement for any specific announcement, but that is not a drawback, it is a nice feature. If you want to have an announcement that you want to identify by a special single field, you are free to implement that in one announcement class on top.
Thanks Doru. Indeed, its a feature, but not a rule which everyone should follow.
Hi Igor and all, just reading this interesting thread...
In other thread, I had proposed to use field to identify an event type instead of class, and someone said that i'm doing it wrong.
I guess you speak about my remark in the "ClassOrganizer oddities" thread. Here is what I said: -------------------------------------
You defined a set of announcement classes, each one is for a particular kind of event. So, no need for #changeKind and #parameters dictionary instance variable (please no!). -------- end----------
just to be clear, the "please no!" was for the dictionary because it can make the code difficult to maintain (Morph properties ...). why not the #changeKind variable even I prefer expressing them by subclasses.
(see the end of this post)
While i thinking that the way how the framework identifies events kinds (by default) not always best one, and as i illustrated its not good for everything.
yes and having a well defined announce hierarchy is not so easy.
that's why for sketching purposes, i'm using dictionary of arguments, not keyword messages and not building a class hierarchy of different change kinds. At this stage it is unclear what follows what, what is the final set of arguments for each change kind, and so i prefer to generate events using less 'early-bound' way.
Cheers Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.