16/02/02 05:06:17, Ross Boylan <RossBoylan at stanfordalumni.org> wrote:

>I also have trouble following your original cutting up of the world,
>but I have a couple of comments that might be relevant.

Thanks Ross, 
I was beginning to think I'd recently been abducted by aliens until I referred to Mark Guzdials first 
book and most of the terms I used are at least mentioned in that book if not detailed (But he used 
GUI toolkit rather than toolkit or widget toolkit).

Perhaps I should cut it up a bit differently.
pluggable (page 147 of Mark Guzdial's first book)
"Three kinds ofpluggable components get used the most in Squeak....All three require a model to be 
specified for their use. Each provides a number of slots for selectors (messages to be sent to the 
model)..."

Somewhere else in the book, unforunately I can't find the page at this present moment. He mentions 
that the orchestrating instance and application model are old paradigms.

So therefore it logically follows that the pluggable component has as its model a direct object, and 
does not have all the vias of an application model or orchestrating instance.

Which makes me wonder why I'm asking this question if I already know.

But... what makes me ask the question is that the example domain model of the clock is quite a small 
domain model (page 143). And the clock class has the behaviour of an orchestrating instance even 
though it hasn't been called so. What if the domain model was larger and the clock wasn't behaving 
like an orchestrating instance. 

It means that an application model would have to be made or that my original question would be yes, 
pluggable components fit directly with objects in the domain.

Are orchestrating classes used in UML or are they obsolete altogether ?

Am I speakin' English.

Regards,
Gary


>First, although Morphs and some of the discussion of them seem to be
>oriented toward having a single object that is both a "model" and a
>"GUI", one can certainly use Morphs in a more classical MVC way.  That
>is, you build an interface out of Morphs, and hook them up with some
>underlying, non-graphical model.  I've been doing this myself, and it
>works fine.
>
>Second, the work with Morphs and players is pointing toward a
>different paradigm, involving tiles, scripting, and direct
>manipulation.  I haven't played with that too much.
>
>Third, there are two different approaches to keeping all the models
>and views in sync.  Morphs have a quality called "liveness", in which
>they periodically update themselves (see the #step method). The more
>traditional way is for a dependent ("view") to register itself with a
>"model" and ask the model to inform it when things change.  There are
>2 generations of that approach.  The classical smalltalk one uses
>update/changed messages.  The newer one uses events, and messages like
>#when:send:... and #trigger.  
>
>The event framework is more aesthetically pleasing to me because it
>allows you to send arbitrary messages (rather than just #update) when
>something happens.  The classical update/change processing usually
>begins with the receiver doing a switch on the "aspect" argument that
>has changed to discover what is going on, which is a little ugly.
>
>I have found there is a noticable overhead with the stepping if you
>have lots of objects (even if they don't step--just going through the
>list of candidates takes time).
>
>