Re: Java Tip 68: Learn how to implement the Command pattern in Java - JavaWorld - February 1999

[<P.H.Welch@xxxxxxxxx>]

Hi Rick (the other one!),

> If I understand correctly, it's not quite correct to call the
> listener-callback mecahnism 'non object oriented' just because it doesn't use
> inheritance. The term often used is the 'delegate model', I believe, as
> distinct from the 'inheritance model'.

But delegation of execution to contained objects is just what any
procedural programming language can do - even C and certainly occam.
So, I don't see `Objects' as contributing anything original here.
The OO community may claim it as a special OO trick, but there doesn't
seem to be anything new in it.  The only new idea, apart from OO-syntax,
is inheritance and everything that flows from that ... so it's those
things that are `Object-oriented' ... nothing else seems to be new?

Of course, if we interpret `Object-oriented' as a phrase from natural
language, the code in active processes *is* written from the point
of view of the object whose behaviour it is describing - i.e. occam
processes are `Object-oriented'.  On the other hand, the code in
methods of passive objects (i.e. almost every class in a typical Java
textbook) is written from the point of view of the invoking thread -
i.e. such object methods are *not* `Object-oriented'.  But I don't have
much luck getting my OO colleagues here to go along with that ...

> The latter is true, except for a very few exceptions. It has to run GUI
> interactions in the JVM Event thread. I quote:
> 
>      Rule: Once a Swing component has been realized, all code that might
>      affect
>      or depend on the state of that component should be executed in the
>      event-dispatching thread.

Thanks Rick.  That clears that up.  But they don't say why?  It may be
just an overkill to avoid the race-hazards of multiple threads doing
this stuff ... i.e. that the less drastic:

<      Rule: Once a Swing component has been realized, all code that might
<      affect
<      or depend on the state of that component should be executed in one,
<      and only one, thread.

may be an equally valid constraint.  Or, it may be that they do some
other thread-unsafe stuff that interferes in an uncontrolled way with
what the Event thread does ... or with what each other are doing to
the screen ... which would be pretty horrible.  I'd still like to find
out ... ;-)

Cheers,

Peter.