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

Magnus Lie Hetland <[email protected]>
Newsgroups gmane.comp.python.anygui.devel
Message-ID <[email protected]>
Dallas Johnston <[email protected]>:
>
> It seems that we are all, more or less, explaining the same beast
> here, with regard to models, only we are having trouble invisioning
> each other's perspectives. This is an all too common error =).

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 :)

[snip]
> So, I would like to try and explain what it is that I have done in
> the simplest terms, all technobabble aside.
> 
> 1) 'A model is only a glorified value,' nothing more, nothing less.
> Thus, a model serves its greatest purpose when observed by some
> other entity for change. Of course, models can provide some measure
> of sophistication, however whatever the magnitude of complexity it
> may encompass, it will always remain a 'glorified value' to the
> outside world.

This, I think is quite OK. Not sure Samuele agrees (especially when it
comes to mutable numbers ;)

> 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.

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.

> It is better that we just get something that works
> for now,

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

> 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... :)

> For now, what follows is what has been done, and it is by
> no means permanent.

Good. (Great work, by the way :)

> model initialisation in the proxy:
> >>> proxy.install/remove<Property>Model(<SomeModel>(...))
> - This was chosen so that model instillation removal can be logically 
>   separated for the benefit of the uninitiated.

OK. (This is similar to the use of link() in my separate new proposal,
I guess... Except for the subsequent attribute magic.)

> a) model.value assigment:
> >>> proxy.<ModelAsProperty> = SomeValue
> - This avoids the modify() goo.

It is also quite magical, and asymmetrical (wrt. the next point).

> b) model assignment:
> >>> foo = proxy.<ModelAsProperty>
> - foo at this point holds a reference to the Model.

This is one of the things that strike me as very odd... I.e.

  foo.bar = something
  somethingcompletelydifferent = foo.bar

Not exactly "least surprise", if you ask me :)

> 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?

And this goes counter to the lazy semantics of push/pull (which was
the motivation for introducing them). Proxy.pull should be called upon
attribute access...

However, of course, such lazy semantics do make real-time updates
impossible. Another issue to resolve.

<sigh>

> d) model evaluation:
> >>> print foo + proxy.<ModelAsProperty>[1:]
> - At this point, the relative method will be called on the Model from the python runtime

Right. This is the same as the model assignment point above;
basically, when accessing the attribute, the model is returned.

[snip]
> Now as it stands, this functionality has been 99% implemented, with
> that last 1% consisting of trivial bugs. Are we not wanting to try
> this code out? As Magnus has already given the OK, I will commit it.

Right-ho. But I'm still not quite convinced about this stuff. :]

> However, lets get things going forward =).
> 
> --Dallas

-- 
Magnus Lie Hetland        Practical Python          The Anygui Project
http://hetland.org        http://ppython.com        http://anygui.org


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.