SystemChangeNotification and Packages

stéphane ducasse ducasse at iam.unibe.ch
Sun Feb 27 08:53:05 UTC 2005


Hi avi

While I agree on your analysis of our intuition with SCN, I disagree 
with your conclusion.
My impression is that if you consider package as first class category, 
then package changes
should be using SCN and seaside and connector should not.  Because soon 
we will want to have
package changes, package list in changesorter.. I think that packages 
are about code entities and
we designed SCN with that vision in mind (package, traits...) should 
use it else this will be the mess later.

Stef


On 26 févr. 05, at 22:57, Avi Bryant wrote:

> On Wed, 23 Feb 2005 10:27:33 +0100, Alexandre Bergel
> <bergel at iam.unibe.ch> wrote:
>> Hello!
>>
>> I was wondering what is the impact of adding packages on the system 
>> change notification mechanism. I added some events for creating a new 
>> package, renaming one, deleting move, moving one method from one 
>> packate to another, ...
>>
>> What about adding a new repository to a package? What about saving a 
>> package?
>
> That's an interesting question, and I guess is really a more general
> one: is the SystemChangeNotification a central registry that any addon
> package for Squeak could/should add new event types to?  For example,
> a NewConnectorsDrawingEvent, or a SeasideApplicationCreated event, and
> so on.
>
> My general feeling is that we don't need this - the main strength of
> SCN is maybe not so much in the architecture for sending and
> registering events, but in all the hooks that have been put into the
> system for sending the events at the right time, and in the particular
> events hierarchy that's been designed for code changes.  For unrelated
> events (and I think package/repository changes are arguably unrelated
> to the current SCN events), the basic #when:send:to: etc events should
> be enough, no?
>
> Avi
>




More information about the Squeak-dev mailing list