2009/11/2 Alain Plantec <[email protected]>: > 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.
(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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
