|
|
Peter,
It's a bit late, but a couple of minor points.
> > [...] From the point of view that I'm taking, this all looks
> > like unnecessary and over-engineered fluff. It provides a level of
> > flexibility which is rarely needed, but which is easy to provide *given
> the
> > current implementation*. A "design burp" in fact.
>
> More than we often need, anyway.
Oh, certainly. I only meant that *from the point of view that the "event
mechanism" is really about message broadcasting* (which is only one viable
POV) these things seem unnecessary.
> A broadcast message always passes one argument, the broadcasting object.
> This keeps everything simple, and it's all that's really needed.
>
> Have a look:
> [snip]
> So, to be a broadcaster you need only those 3 methods. Note that this is a
> *complete implementation*, not just some excerpts of the code.
Impressively simple (dontcha love it!). I suspect that it'd be slightly
_too_ simple for general use, though since it doesn't use weak links and I'd
rather be able to send more or less than one parameter. For your intended
use it sounds like an excellent fit to requirements.
BTW, the method #ifNil: isn't part of standard Smalltalk, Dolphin doesn't
have it, for example (which, I understand, is because there is some
inconsistency between the dialects that do have it).
> > However, we've also increased the coupling between observer and
observee,
> in
> > that there is now an increased chance of conflicts between the names of
> the
> > methods that the observee broadcasts, and the method names used by its
> > observers. That is an inherent downside, I'm afraid, but the effects
can
> be
> > minimised by sensible choice of method names.
>
> I don't think there's any issue there that can't be easily dealt with by
> using an adapter for protocol conversion. I love it when I get more
patterns
> in :-).
>
Well, I'd say that the coupling is still there -- it manifests as the
programmer having to think about *whether* to use an adapter. The only way
around that is to use adapter routinely, whether it's needed or not. In
fact one can think of the Dolphin event system as providing a built-in
protocol adapter.
> > First off, notice that the ordinary "definitions" and "references"
> browsers
> > work correctly with these new broadcast messages without any changes to
> the
> > system at all. I think that's a good start in itself.
>
> Only one problem that I see, and it's that my IBM VisualAge/VA Assist
image
> doesn't find the method with a broadcast Symbol in a literal array as a
> sender of that Symbol. Wonder if that's a setting, and what Dolphin does.
Dolphin's (I believe) goes exactly one level deep into literal Arrays. I'm
not sure if OA are intending to extend that (or may even have done it and I
haven't noticed).
> Peter van Roooijen
-- chris
|
Locked
