Re: Going on, but first some clarification...

Magnus Lie Hetland <[email protected]> wrote:
>Indeed... However, I'm not sure that we agree on how this should work.
>We may have similar ideas, but there are differences, I believe :)

What I am referring to is the fact the we all agreed before on the theory of model behaviour, not necessarily the mechanism of its postulate. I do realise, however, that you and Samuele disagree (as has been recently conveyed) as to the proper bahaviour of mutable numbers and such...

>> 2) The semantics of the actual initialisation and assignment is
>> really only peripheral to the issue at hand, and largely subject to
>> personal bias.
>
>Maybe. But it may profoundly affect the semantics of properties in
>Anygui, something which should not be taken too lightly.

I think that what I was trying to emphasise was that any one of them may work, only that the desired semantics vary according to taste. 

-- By the way I would like to add that I don't necessarily think that the model/attribute magic is all that pleasing. Incedentally, I was just implementing it as I thought you originally desired it to be done, i.e. not all that different from the way that models worked in the old architecture. In my personal experience I have never had models behave in this manner. Models have always been far more generic and decoupled, aside from their ability to register observers and publish APIs for updating their internal  data structures. So, I must admit that what was being aimed for was not exactly ideal. I just proposed an implementation for what I thought was the target spec. And in light of that, I thought that the delegate idea was by far the cleanest way to go about hitting that target. Now the target moves =/.

>As I see it, there are now three variant semantics:
>
>1. The alias variant/copy semantics (you can't "bind" these properties
>   to anything)
>
>2. The current "proper" property semantics (you do "bind" them to a
>   value, which may be modified in-place)
>
>3. The proposed model property semantics (as I understand it from your
>   proposal, assigning to it has the effect of binding model.value to
>   the assigned value, and accessing the attribute returns the model
>   itself)
>
>There are things to be said for simply using version 1, and dropping
>version 2. (This would require dropping properties bound to models.)
>With the current in-place-modification semantics of MVC, we need
>version 2 as well. Version 3 strikes me at first glance as an
>abomination <wink>, but I haven't had time to give it much thought
>yet.

Yes, version three does invovle quit a bit of slight of hand... Now you see it... now you don't =).


>Or that we drop Models until we have proper use-cases and see how we
>want them implemented...

Well, I think that we will have a hard time coming up with any use cases for the whole of Anygui, in its current condition.

>> and modify that as we all see fit to represent the greater
>> consensus.
>
>Right. But that should hopefully be done at *least* before we put out
>a beta... :)

And I was hoping to get this done before then, but I'm not going to touch it anymore, as it seems you have already decided for everyone that Models, as they are now currently implemented, are going to be chucked out the door.

>> c) user manupulation of the model via the GUI:
>> # user inputs some data
>> # model is updated accordingly via the call to Proxy.push by the wrapper 
>
>Here I assume you mean Proxy.pull?

Sorry, got that backwards.


__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf