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