Hi Andreas,

Andreas Raab escribió:
> [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?
>
I agree that "That it's a wonderful architecture for direct 
manipulation". I don't agree with "That it's a terrible architecture for 
building reusable systems". I don't agree with "makes it very hard to 
build re-usable and flexible components."
>> "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.
>
I see no need for something called a "graphical model" and not just a 
model as in MVC, etc.
>> 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). 
yes.
> 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>).
>
I missed that. How do you reference signaler? I mean, each instance of 
the handler could want events from a particular signaler, perhaps one 
that still doesn't exist when you compile the method! Perhaps it is an 
instance variable of the handler?
> 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.
>
If you prefer it, that's ok.
> 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).
I find both to be quite graphical, and quite interactive. I don't know 
what you mean here.
>
> 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.
That's not a property of the graphic frameworks but of the models being 
observed. And those models are not part of the framework. Of course the 
models could trigger events. But these examples show that not even that 
is needed. So, I don't see the need for a "theory of viewing". You see, 
any model can work. That's the fundamental idea of the separation of 
View and Model as in MVC. The model is outside of the framework. It can 
be any object.
>
> 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
Of course you know you can also use events. I guess you're just kidding.
And I agree with you, Morphic doesn't specify a "viewing architecture". 
And there's no need for one.

Cheers,
Juan