SystemChangeNotifier and Announcements

I've been playing in a part of the sandpit where I'm getting interested
in SystemChangeNotifier. There was mention some time ago of refactoring
it to use Announcements. Did that end up going anywhere? Is there
anything I should look at before I roll up my sleeves and get stuck in?

Also, quite separately, are there plans to have Announcements in core
Squeak any time soon?

Regards,
  Tony

Tony Garnock-Jones wrote:
> I've been playing in a part of the sandpit where I'm getting interested
> in SystemChangeNotifier. There was mention some time ago of refactoring
> it to use Announcements. Did that end up going anywhere? Is there
> anything I should look at before I roll up my sleeves and get stuck in?

Go for it! Nobody has done anything yet.

> Also, quite separately, are there plans to have Announcements in core
> Squeak any time soon?

A compelling use case would help :-) although I'd be fine with it
regardless.

Cheers,
   - Andreas

On 25 February 2010 03:10, Andreas Raab <[hidden email]> wrote:
+1 it would be good to replace the SystemChangeNotifier with Announcements.

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

Hi,

>>> Also, quite separately, are there plans to have Announcements in core
>>> Squeak any time soon?
>>
>> A compelling use case would help :-) although I'd be fine with it
>> regardless.

We have a fairly complete Announcements implementation based on Vassili's blog.
Its license is MIT. We just uploaded a new version: Announcements-klub.1 [1]
with the AX prefix stripped from it. I would be happy to help with
reimplementing
SystemChangeNotifier using it.

Balázs

[1] http://www.squeaksource.com/AXAnnouncements.html

Hi,

> I would be happy to help with reimplementing SystemChangeNotifier using it.
I've actually started this. My plan is that:

 - In the first turn we create SystemChangeAnnouncer which mimics
SystemChangeNotifer workings, and Announcement classes [1] mimicking
AbstractEvents.

 - If this is all done, we replace the SystemChangeNotifier unique
instance with a SystemChangeAnnouncer instance.

 - Finally we start to rewrite SystemChangeNotifier usages, e.g.
breaking up the big #event: methods
to more fine grained subscriptions.

If I am getting anywhere, i'll upload it to the AXAnnouncements repo.
Anybody interested in this? What do you think about the approach?

Balázs

[1] First stab at the announcement hierarchy combining all changeKinds
with their supportedKinds in AbstarctEvent subclasses:
SystemChanged
  CategoryChanged
     CategoryAdded
     CategoryModified
     CategoryRemoved
     CategoryRenamed
  ClassChanged
     ClassCommented
     ClassDefinitionModified
     ClassModified
     TraitDefinitionModified
     ClassRemoved
     ClassRenamed
     ClassReorganized
     ClassRecategorized
     ClassAdded
  ExpressionChanged
     ExpressionDoIt
  MethodChanged
     MethodAdded
     MethodModified
     MethodRecategorized
     MethodRemoved
  ProtocolChanged
     ProtocolAdded
     ProtocolModified
     ProtocolRemoved
     ProtocolRenamed

-Ralph

Balázs Kósi wrote:
> [1] First stab at the announcement hierarchy combining all changeKinds
> with their supportedKinds in AbstarctEvent subclasses:

The Deltastreams code uses SystemChangeNotifications of course, and we
did a few tweaks in order to have the events carry ALL information about
the change - which it didn't always do. One example was the class
comment change - it didn't carry the OLD comment.

So if you are about to rewrite all this - please make sure to carry both
state BEFORE and AFTER.

regards, Göran

Hi,

> The Deltastreams code uses SystemChangeNotifications of course, and we did a
> few tweaks in order to have the events carry ALL information about the
> change - which it didn't always do. One example was the class comment change
> - it didn't carry the OLD comment.
>
> So if you are about to rewrite all this - please make sure to carry both
> state BEFORE and AFTER.

Sure thing.Does this means that you added new methods to SystemChangeNotifier
which creates those extended events, and changed the places where they
are triggered?
I've looked into the DeltaStream repo [1], but couldn't find anything related.
Can you show me where to look?

Balázs

[1] http://www.squeaksource.com/DeltaStreams.html

On a sidenote: The comment of SystemChangeNotification-Tests-gk.11
says "I am not sure why we are sending a class category along when we
change a class comment?"

This bugs me also. It's not clear to me, why we are sending in the
category at these methods of SystemChangeNotifier:
  classAdded: inCategory:
  classCommented: inCategory:
  classRemoved: fromCategory:
  classRenamed: from: to: inCategory:
I would think that in all these places the class category is the same
as the category passed in the parameter.

Balázs

Balázs,

i'm only asking to use events, which can be cancelled by subscriptors.

And it would to use following scheme:
- notify _before_ change going to be made
- apply change
- notify _after_ change is made.

So, i expecting to have events to work using following scheme:

event := MethodChangeAnnouncement new action: [ here the action  ].
self announceBeforeChange: event.
self apply: event.
self announceAfterChange: event.

in this way, a subscriptor could tell 'event cancel',
And then in #apply: it will be a no-op.

SomeChangeAnnouncement>>action: aBlock
  action :=  [ aBlock value. applied := true ].

SomeChangeAnnouncement>>cancel
  action := nil.
  applied := false.
  cancelled := true.

....

--
Best regards,
Igor Stasenko AKA sig.

Balázs Kósi wrote:
Yes, we did.

> I've looked into the DeltaStream repo [1], but couldn't find anything related.
> Can you show me where to look?

Hmmm, I will try to take a look, a bit busy here but...

cheers, Göran

Hi!

Balázs Kósi wrote:
> I've looked into the DeltaStream repo [1], but couldn't find anything related.
> Can you show me where to look?

Hmmm, I think (was some time since I hacked on DS) we kept these
separately as a cs, and I think this is all of it
  (attached).

regards, Göran