Folks -
While doing some preferences stuff I ran into one of my "most-hated" issues in Squeak. Anyone who has ever encountered SystemChangeNotifier must have noticed how terrible it is to use it. I mean, just look at this code: prefEvent: anEvent "Check if this system event defines or removes a preference." (anEvent itemKind = SystemChangeNotifier classKind and: [anEvent isRemoved]) ifTrue:[...]. anEvent itemKind = SystemChangeNotifier methodKind ifTrue:[ (anEvent isRemoved or:[anEvent isModified]) ifTrue:[...] (anEvent isAdded or:[anEvent isModified]) ifTrue:[...] ]. just needless, pointless lines of case statements. How do people feel about replacing that mess with Announcements? If you really want to have all events you register for SystemEvent and if you'd like to be more specific you go for more specifically for ClassEvent or even more specifically for ClassAddedEvent. It would also remove the need for all of these weird tests like anEvent itemKind = SystemChangeNotifier methodKind and:[anEvent isRemoved] and just replace them with something like "anEvent isMethodRemoval". It would likely be faster too, since most places aren't really interested in *all* events either. It would mean that Announcents would have to go core but this cleanup alone seems worth it. I also suspect that adding Announcements and fixing SystemChangeNotifier may remove more code than it would add. How do people feel about that? Cheers, - Andreas |
> > It would mean that Announcents would have to go core but this cleanup > alone seems worth it. I also suspect that adding Announcements and > fixing SystemChangeNotifier may remove more code than it would add. > > How do people feel about that? > > Cheers, > - Andreas Sounds good to me. Keith |
In reply to this post by Andreas.Raab
Andreas Raab <andreas.raab <at> gmx.de> writes:
> ... snip due to gmane policy :( ... > > anEvent itemKind = SystemChangeNotifier methodKind and:[anEvent isRemoved] > > and just replace them with something like "anEvent isMethodRemoval". It > would likely be faster too, since most places aren't really interested > in *all* events either. > > It would mean that Announcents would have to go core but this cleanup > alone seems worth it. I also suspect that adding Announcements and > fixing SystemChangeNotifier may remove more code than it would add. > > How do people feel about that? > > Cheers, > - Andreas > > Sure. ++ for Announcements. But one thing just annoys me: uncontrolled proliferation of #is* messages. Why general Announcement framework should know about every specific annoucement for example implementing isMethodRemoval ? That makes me think of the Newspeak doesNotUnderstand hack which install an invisible ^false method at root object... Nicolas |
nicolas cellier wrote:
> Sure. ++ for Announcements. > But one thing just annoys me: uncontrolled proliferation of #is* messages. > Why general Announcement framework should know about every specific annoucement > for example implementing isMethodRemoval ? Ah! But that's one of the points of using Announcements. You don't have to add it too high in the event hierarchy, since you can scope down to where you need it. E.g., consider this hierarchy: Announcement SystemEvent CompilationEvent ClassCompilationEvent ClassAdditionEvent ClassModificationEvent ClassRemovalEvent MethodCompilationEvent MethodAdditionEvent MethodModificationEvent MethodRemovalEvent Now, only CompilationEvent does need to know about #isMethodRemoval since you can do, e.g., registerForEvents SystemChangeNotifier on: CompilationEvent send: #prefEvent: to: self. Cheers, - Andreas |
In reply to this post by Andreas.Raab
On Thu, 2009-03-05 at 21:32 -0800, Andreas Raab wrote:
> Folks - > > While doing some preferences stuff I ran into one of my "most-hated" > issues in Squeak. Anyone who has ever encountered SystemChangeNotifier > must have noticed how terrible it is to use it. I mean, just look at > this code: > > prefEvent: anEvent > "Check if this system event defines or removes a preference." > (anEvent itemKind = SystemChangeNotifier classKind and: [anEvent > isRemoved]) ifTrue:[...]. > anEvent itemKind = SystemChangeNotifier methodKind ifTrue:[ > (anEvent isRemoved or:[anEvent isModified]) ifTrue:[...] > (anEvent isAdded or:[anEvent isModified]) ifTrue:[...] > ]. > > just needless, pointless lines of case statements. How do people feel > about replacing that mess with Announcements? If you really want to have > all events you register for SystemEvent and if you'd like to be more > specific you go for more specifically for ClassEvent or even more > specifically for ClassAddedEvent. It would also remove the need for all > of these weird tests like > > anEvent itemKind = SystemChangeNotifier methodKind and:[anEvent isRemoved] > > and just replace them with something like "anEvent isMethodRemoval". It > would likely be faster too, since most places aren't really interested > in *all* events either. > > It would mean that Announcents would have to go core but this cleanup > alone seems worth it. I also suspect that adding Announcements and > fixing SystemChangeNotifier may remove more code than it would add. > > How do people feel about that? > you can have specific dependencies that don't need any monkey patching. I didn't know SystemChangeNotifier but while you are hunting I want to point you to EventManager which might be replaced after Announcements found their way into the image. Norbert |
In reply to this post by keith1y
> >
> > It would mean that Announcents would have to go core but this cleanup > > alone seems worth it. I also suspect that adding Announcements and > > fixing SystemChangeNotifier may remove more code than it would add. > > > > How do people feel about that? > > > > Cheers, > > - Andreas > Sounds good to me. > > Keith +1 as well, Announcements should be in the core and it's a tiny framework that many of us use anyway. Ramon Leon http://onsmalltalk.com |
+1 SystemChangeNotifier is nasty (especially when unloading stuff that
doesn't deliberately handle de-registration). A more "removal tolerant" system would be nice. Regards, Gary ----- Original Message ----- From: "Ramon Leon" <[hidden email]> To: "'The general-purpose Squeak developers list'" <[hidden email]> Sent: Friday, March 06, 2009 5:30 PM Subject: RE: [squeak-dev] An old gripe (or: SystemChangeNotifier+ Announcements = Sanity?) >> > >> > It would mean that Announcents would have to go core but this cleanup >> > alone seems worth it. I also suspect that adding Announcements and >> > fixing SystemChangeNotifier may remove more code than it would add. >> > >> > How do people feel about that? >> > >> > Cheers, >> > - Andreas >> Sounds good to me. >> >> Keith > > +1 as well, Announcements should be in the core and it's a tiny framework > that many of us use anyway. > > Ramon Leon > http://onsmalltalk.com > > |
Free forum by Nabble | Edit this page |