Igor Stasenko wrote: > 2009/11/1 Tudor Girba <[email protected]>: > >> 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. > 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. Cheers Alain _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
