Announcements

Vassili just made a post on the Cincom blogs about the new event
framework they're going to introduce into VisualWorks at some stage...

http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&entry=3310034894

I actually wondered why (Coming from .NET) Smalltalk didn't have real
objects
for event notification, and instead relies on symbols. C#/VB.NET have
delegates/event handlers/event arg subclasses for publishing events....

Anyways.. What are peoples thoughts on something similar for Dolphin?

Perhaps even an OA blessed version some point in a not-too-distant future?

It sounds good.

The idea seems to be ObjectOriented.

Just some remarks:
- it would be good to have more details, especially about the planning
and  implementation decisions.

- perhaps at least conceptually we can extend the "object" concept to
something like "agent", which has not only attributes and methods, but
also events built in. (although Vassily writes on event objects on
their own, i.e the idea can be implemented within the OO paradigm)

- does not it mean (also with the present event handling effort) that
we are in a similar situation with events as we are with the "reading
records and fields from external sources and convert them to objects"?
I mean here that the origin of events come from the external word, like
the operating system behavior (you may remember to the interrupts from
the old DOS time).

And here we are again: in the most general form the whole complexity of
handling asynchronous "events" comes up together with threads and
asynchronous processes: something happens at a not determined point of
time, to which my objects (or agents) should react.

But as Vassily outlined it, the concept seems to be clean, and simple.
It will be good to see, how it works in a really dynamical and
expandable and scalable environment.

Best regards,
Janos

Sean M wrote:

> Vassili just made a post on the Cincom blogs about the new event
> framework they're going to introduce into VisualWorks at some stage...
>
>
http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&entry=3310034894

Very interesting.  I've been pondering almost exactly the same idea for some
time now, and it's a direction I'd love to see Dolphin move in (but /not/ in
this release !).

IMO, the biggest single problem with Symbol-based notification is that it is
very difficult to extend as software changes.  As one real example, OA have
apparently realised that the #itemRemovedAtIndex: event that ListModels used to
generate does not contain enough information -- by the time the event has been
generated, the item has been removed, and knowing where it /used/ to be is not
helpful if you want to know /which/ element has been deleted.  So now there's
an entirely new notification #item:removedAtIndex:, but old code doesn't
automatically pick that up, so ListModels now have to generate two
notifications.  Another example is the notification the system generates when
methods are added or changed.  In this case OA choose to make it generate a
notification with a single data object as parameter, the data object (a
CompilationResult) contains all the interesting info.  That's much more
flexible, and can (and has IIRC) have new stuff added to it easily, and
outdated stuff removed fairly easily (at minimum, things fail noisily rather
than silently).

I think that a framework along the lines that Vassili describes could be
layered over the current stuff.  Basically an 'announcement' would be
implemented as:

    self trigger #announcement: with: anAnnouncement.

Alternatively, it might be better to start from scratch.  I'm not sure about
the idea of block-based handlers, though.  Can anyone remember why the current
event system doesn't directly support handler blocks ?  As in:
    anObject when: #event do: [... do something].
I think it was because it kept object references for too long, or maybe they
weren't kept long enough...  Anyway, whichever problem it was, the same problem
would presumably occur if blocks were used as announcement handlers.

Incidentally, a completely different way of approaching the same general idea,
but without effectively abandoning the current system, would be to allow
wildcards in event handlers.  Possibly the two ideas could even be merged, so
that a Symbol was just one possible kind of Announcement, and a wildcard
pattern was just another kind of AnnouncementFilter.

Another point: Vassili only mentions exceptions in passing, but I think there's
a fairly deep connection between the two ideas -- more than just a conceptual
similarity -- in that a raised exception is very like an announcement triggered
off the current thread.  I don't know if there's any real mileage to be gained
by exploring that, but I'd want to think more about how threads (sorry,
Processes) and announcements connect.  It would be nice to be able to specify
which thread (sorry, Process) should execute a given handler for a given
announcement.  In the extreme the notions of thread (sorry, Process),
exception, announcement, and continuations could all be bundled up into one
general concept of "throwing" data from one execution context to another.
Vanilla announcement would throw information across encapsulation boundaries,
threaded announcements would throw data between Processes, exceptions would
throw information "up" the stack, and continuations would throw information
into the past.

Just thoughts...

    -- chris