Events vs dependency

Hi,

Where can I find some tutorial on Events and how they relate to
dependency?

Thanks

Fernando,

> Where can I find some tutorial on Events and how they relate to
> dependency?

"Events" and "Dependency" are two different frameworks, there is no
relationship between them (other than the problem they are trying to solve).

I'm sure you've noticed that although Dolphin implements a dependency
mechanism it doesn't use it at all, it's just there to make porting from
other dialects a bit easier - for example, the RB uses it.

There is a page on the WIKI that compares the two, written by Andy Bower
and referenced in the WIKI by Bill.  I'm not sure what the state of the
online WIKI is at the moment so I've copied it from my DSDN archive.   I
hope nobody objects.

--==--==--==

Andy Bower on Events vs. Dependencies
Despite the nice summation in the Observer pattern sheet, I still think
there's value in reading the following, which is a somewhat dated piece
that AndyBower wrote on the subject. A more recent preamble describes
the setting, which sounds very reminiscent of the Beta 2c era.
--BillSchwab

I dug this out of my archives. When reading it please remember it was
written at a time when most of the leading Smalltalks (VSE, VW, VAST)
and Dolphin were only just getting wise to weakness and finalization. It
also talks about an MVC architecture which was before we adopted MVP in
Dolphin.



--------------------------------------------------------------------------------

Dependency versus events Originally posted in comp.lang.smalltalk.

The Dependency mechanism is part of the "Smalltalk standard" since it
has been in the image since the original Smalltalk-80 to help when
implementing what is effectively the Observer pattern (Design Patterns,
Gamma et.al). More recently it has been upstaged by the Event mechanism
introduced in the upstart Smalltalks (just a joke chaps) of
Digitalk/IBM/ObjectStudio.

Newcomers to, and indeed more seasoned users of, Smalltalk sometimes
have difficultly in deciding which of these two mechanisms to use. I'd
like to present what I think the issues are and perhaps promote some
further comment.



--------------------------------------------------------------------------------
Dependency allows an observer object to register an interest in ALL
aspects of another object. The observer then has to sort out what
actually changed at runtime so it can so something sensible with it.
Events allow an observer to be interested in a specific aspect of a
publisher and even request that a particular message is routed to them.
Then, when the publisher triggers an event the routing and any message
adaptation is automatic.
Clearly there is a trade off here. Dependency is easy and fast to set up
at initialization time and has a simple and fast mechanism underneath.
The loading is at runtime, since the observer's must all do the event
decoding and re-dispatching after the update is received.

The Event mechanism puts the onus on the programmer to route the
messages at initialization time but the runtime is fast. The underlying
mechanism is more complex and for many event registrations can generate
a hefty number of objects (but hey, we've all got 24Mb surely).

Dependency does have some other advantages. If you have a layered
architecture where:

observer -looksAt- applicationModel -looksAt- domainModel

It is quite easy to arrange that updates from the domainModel are
propagated directly through to the observer (you don't want to make the
observer depend directly on the domainModel since this breaks
thelayering encapsulation). This only needs two dependency links as
shown above and can be done in a generic way by the applicationModel. To
do this using Events is much more complex since the AM must register an
interest in ALL the events of the DM in order that it can pass them on.
Not only is this onerous but if the DM adds a new event then all the
layers must be changed.

Maybe Events just have it over Dependencies. But let's dig deeper...

Both mechanisms require that extra references are held on the observer
objects by the registry in use. Indeed, if a global registration system
is in place (the default) then the publishers also have an extra
refernce held. These "non-essential" references will obviously keep
these objects alive when all other references have gone. This means that
objects need to explicitly send "release" to themselves to break the
links and allow them to die (sounds like a C++ delete to me, and I don't
really want pay whatever penalty it is for garbage collection if I still
have to explicitly free up memory).

Still both Dependency and Events have the same problem. It's just that
executing release for Dependency is fast and simple because the object
only has to be removed from one collection. For Events, an object must
be removed from all the event chains that it's in, and these chains
folded down when complete. This is expensive. There is a way around this
if your Smalltalk supports Weak Collections and finalisation. The
registries can then hold onto their references in WeakArrays? which
don't keep the contents alive by their reference alone. Similarly
objects can vanish from them without having to be explicitly removed.
This would alleviate the performance penalty paid when using "release"
and the Event mechanism. It also means that your virtually never have to
call release.



--------------------------------------------------------------------------------

So my advice would be:

Get a Smalltalk with Weakness and finalization. Most that I know of
support this in their latest versions. VisualWorks VisualAge
VisualSmalltalk? (not at v3.0) but later

I'm not sure about ObjectStudio?

Dependencies or Events; make sure that whichever mechanism you choose
uses a a registry with weak references. Then you don't explicitly have
to send release. It is interesting that VW supports weakness but the
Dependencies don't use it. It's easy to implement Dependency yourself
using WeakArrays? but implementing an efficient Event mechanism in this
way is much harder. It can be done but you'll have to be clever. Given
this then I think Events have it over Dependencies for linking to user
interfaces which (certainly in MVC) should talk only to one layer. This
is because they are easier to program and maintain. In the case of
Application Models or intermediate layers then Dependency should be
seriously considered for the propagation reasons previously discussed.

Debugging Events can be easier, because all the distribution information
is held in the registry and not held partly in code as it is for
Dependencies. If needed, you can build tools to query this registry.

Be aware of the performance issues on either side. If you don't have
weakness then you may find that Dependency is a better choice because of
the faster "release" process.

--AndyBower (placed here by BillSchwab)



--==--==--==


--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.