Status: Accepted
Owner:
[hidden email]
CC:
[hidden email],
[hidden email]
Labels: 1.5
New issue 5174 by
[hidden email]: Integrate SystemAnnouncements
http://code.google.com/p/pharo/issues/detail?id=5174What I'd want to see as such out of a Core inclusion, is basically
inverting the dependencies between SystemEvents and SystemAnnouncements,
making the old system an unloadable package.
If we were to include SystemAnnouncements in 1.4 Core in its current state,
you'd still need to keep SystemEvents around due to heavy dependencies,
basically including duplicate frameworks.
As far as maintaining SystemAnnouncer as an external package, you can't get
much better than is now (except some renaming s, and maybe an extra
abstract layer of Announcements*).
While the Announcements registering and event handling is a more pleasant
experience, I therefore vote to keep it external from the release for the
time being.
I do think it's a good thing to have it included in alpha-versions though,
as doing the above is a hard task otherwise.
* Either what in Events are called "*kind" (Class/Method etc.), or based on
action (Removed/Added/Changed), depending on which you are more likely to
want to differentiate between.
In other words, if it is more common to say "If something happened to a
class, I need to ...", or "If something was added, I need to …" where in …
you fill in an action which doesn't
** Some steps needed for letting SystemAnnouncements be the sole entity in
a base image responsible for broadcasting changes, and keeping
backwards-compatability as an external package:
-1a) Change SystemAnnouncement names, dropping System-prefix and
-Announcement postfix. (I believe Nautilus is currently only external user,
sorry Benjamin :/) This is the only step done already, in Issue 5172
-1b) See *
0) Optimize #subscribe:send:to: (avoid MessageSend #numArgs send when
culling), since SystemAnnouncements need to use that in order to register
weakly. See issue 5173
Hither follows the actual steps, each number corresponding to where I think
you'd need distinct .mcz updates:
1a) Internalize state in Announcements, instead of using data from Events.
1b) Implement SystemChangeNotifier protocol on SystemAnnouncer, in
extension protocol *SystemEvents, so external consumers will register
correctly when loaded (but receive polymorphic Announcements instead of
Events).
1c) Implementing announcement-handling methods on current
Event-consumers(ChangeSet, SmalltalkImage, RecentMessageList, TestCase,
TestRunner, etc.) in Core.
2) Migrate current Event-consumers from SystemChangeNotifier to
SystemAnnouncer
3) Switch SystemChangeNotifier uniqueInstance to SystemAnnouncer.
4) Remove all contents in System-Change Notification except
SystemChangeNotifier's class method.
5a) Make new package from SystemEvents extension protocol.
5b) Store SystemEvents package in external repository, remove from Core.
_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Locked
