[Changing the subject since this part seems to be mostly about viewing]

Juan Vuletich wrote:
> For example, I don't agree at all with "Morphic is a wonderful 
> architecture as far as direct manipulation is involved but it's a 
> terrible architecture to build reusable systems. Morphic simply doesn't 
> have any abstractions and that makes it very hard to build re-usable and 
> flexible components."

Which part do you disagree with? That it's a wonderful architecture for 
direct manipulation? That it's a terrible architecture for building 
reusable systems? That it doesn't have abstractions?

> "Because MVC is a "viewing architecture"... Tweak ... provides a viewing 
> architecture similar to MVC." I don't agree with this either. In Tweak, 
> a player knows its primary costume. In MVC, one of the key ideas is that 
> a view knows its model, but a mode knows nothing about the views on it. 
> I believe the viewing architecture to be quite different.

You're actually only looking at a part of viewing in Tweak - namely that 
of graphical models which indeed know their primary views. This is not 
generally true - all that is required for viewing in Tweak is that an 
object #signal: the occurrence of an event that a view can observe 
(which is very much like MVC's change/update mechanism except that it 
executes asynchronously by default and is supported and used all the way 
top to bottom in Tweak). And many Tweak objects act as views on numerous 
other objects (indeed, part of the implementation of Tweak depends on 
objects "viewing themselves").

For *grapical* models (players) it is indeed true that they know their 
primary view (the costume) but this is mostly to optimize management of 
some state (which is held exclusively in the costume). I actually 
debated this for quite a while initially and went for it due to the 
space savings, but I may (have to) reconsider it in the context of 
Croquet simply because there may be no notion of a "primary" view for a 
(replicated) model under a (non-replicated) viewing environment.

> WRT method annotations for event handlers, it seems as if the receiver 
> of the message for some object was always the object triggering the 
> event. Usually it is not. It could be an owning morph, or the model(if 
> the event is from the gui), or the view (if the event is from the 
> model). This is also related to the model not knowing about the view in 
> MVC.

I presume that by "the receiver of the message for some object was 
always the object triggering the event" you mean that the signaler and 
the handler of the event are the same (if not, please clarify). If 
that's what you mean then you are right, usually they are not the same. 
This is why you have <on: eventName in: signaler> annotations (and the 
common <on: eventName> is effectively shorthand for <on: eventName in: 
self>).

Part of the goal for these annotation is that for many applications it's 
nice to be able to "centralize control" in a single place. In other 
words, I often prefer a style that uses:

onFireInMyButton
    "MyButton has been fired. Carry out some action."
    <on: fire in: myButton>
    target doButtonAction.

to one that uses, e.g.,

    button on: #mouseDown send: #doButtonAction to: target.

The latter version certainly has its uses but I find the former much 
more accessible in terms of looking at a class and how it defines the 
relationship between the entities it deals with (in particular in a 
Tweak browser where event methods have icons so that you can immediately 
see which of them are event responses).

Another major advantage is that when I need to add/change/remove one of 
these events I don't have to poke around all over the places to find 
where the button is initialized and change other people's code - I can 
write a clean new method, state the relationship right there and then 
and get the result. Plus, renaming and changing events doesn't require 
me to execute manual code (the system takes care of transferring the 
triggers), nor does it require me to manually change event relationship 
if the button ever changes (again, Tweak transfers the event responses 
automatically when you change a field). [there are numerous other 
advantages that I won't list here because this is getting excessive already]

And just for completeness, there is of course a way to do the 
programmatic equivalent of the latter via:

   target startScript: #doButtonAction when: {button. #fire}.

So the bottom line is, you're right, often the signaler and the handler 
of an event aren't the same and Tweak supports that common use case too. 
And I would claim that it supports this use case better than Morphic 
ever could.

> ScorePlayerMorph and EnvelopeEditorMorph are good examples of views on a 
> model, in the classic MVC idea of the view knowing about the model, and 
> the model not knowing about the view. I don't see the need for a "theory 
> of viewing". It is enough with separating the view and model 
> responsibilities, and triggering events, just as in MVC.

Interesting. For two reasons really. First, I wouldn't even consider 
these to be "morphs" but rather what I would call "application shells". 
By which I mean there is nothing intrinsically graphical about the two, 
nor even anything interactive - neither of the two chosen examples 
implements drawing or event handling (mouse or keyboard) which given the 
definition of a Morph as:

[Morph classComment]
	A Morph (from the Greek "shape" or "form") is an interactive graphical 
object.

strikes me as non-Morphic as it gets (given that the two defining 
properties of being graphical and being interactive aren't met).

But besides, you do realize that both of the examples you are mentioning 
are polling in their step methods for any changes in the model, right? I 
think one could consider this a form of viewing but I don't consider 
step-polling to be an actual viewing architecture because it gets very 
excessive pretty quickly. Case in point: PianoRollScoreMorph. It polls, 
too, and when it detects a change in its model it recreates all these 
morphs from scratch (besides the criticism implied here it's actually 
quite impressive how well this works). However, given current Morphic 
usages step-polling seems to be the prevalent method of determining 
changes in Morphic.

So, I guess I have to correct myself, Morphic does indeed support 
viewing via step-polling (but I still wouldn't call that a viewing 
architecture ;-)

Cheers,
   - Andreas