Re: I'm still here...

Dallas Johnston <[email protected]>:
>
> Magnus Lie Hetland <[email protected]> wrote:
> >Not absolutely. I just thought it might be nice to put this in
> >widget.push(), to avoid having the check in every setter in every
> >back-end...
> 
> That's what I thought should be happening aswell. And this behaviour
> exists now in the push method. However, this didn't prove to
> suffice, and I needed to place if clauses in most of the back-end
> get/setFoo methods for anygui to even work.

Strange.

[snip]
> >What do you say? Is this an acceptable version of the scheme?
> 
> Depends. For all practical purposes, whenever the model is relied
> upon for any data, after having been returned by proxy, any
> manipulation of the value that the model represents is managed by
> the model itself, which is attrictive for encapsulation purposes.

You are right.

> So, if what you are suggesting is the following:
> 
> >>> foo = proxy.foo # where foo now contains the *value*, not the
> model
> 
> ... then I must ask if the user should expect foo to be mutable in
> syncopation with the model, or that the value foo has been orphaned
> off at this point?

Right.

> >I think the model installation method sounds good, if it is
> >possible to have the relevant object properties behave (more or
> >less) like normal properties, and only have the model mirror that
> >property (i.e.  not have it returned upon property access).
> 
> This is actually what the code does internally. Model only really
> overshadows value. So when the call to self.wrapper.pull(state) is
> performed, the attribute that model represents is now in state, and
> the model is updated according to that value, then state[prop] is
> replaced before the call to self.state.update(state), an extension
> to the lazy semantics in Attribs I guess...

Sounds good.

[snip]
> I'm open to, just don't want to feel that I wasted time =).

Indeed -- I'm sorry (as I've stated previously) if I gave you that
impression.

I don't think you've wasted your time, but as I'm sure you've noticed,
I may sometimes be ruthless in butchering code (especially my own)
<wink>. Anyway, I think it's important that we end up with a way of
doing this that we've all (at least those of us discussing it ;)
thought through and that we're all (more or less ;) pleased with.
After all, once we start releasing stuff for 0.2, it's going to be
progressively harder to change existing syntax or semantics...

> >BTW: Could installFooModel be used to install more than 1 model?
> >(The link() scheme could.) 
> 
> Well, by more that one model, do you mean more than one FooModel
> existing for foo at any given time? Wouldn't that be rediculous?

I guess so. I'm probably mixing up models and views here. One model --
many views (and potentially many controllers, I guess).

> Howerver, if you meant that one model may represent more than one
> value at a time, yes. This is now possible, and Assignee handles
> multiple value sources.
> 
> >This could make sense, but could also be a bit weird... I guess the
> >models would then be sync'ed with each other through the Attrib
> >object...
> 
> Maybe I don't get where you want to go with this idea. Any examples?

Don't sweat it -- it was'nt important at all, I think.

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