Re: Models...

Samuele Pedroni <[email protected]>:
[snip]
> but as values your models can be mutable variant of immutable types, e.g.
> a int subtype that can change value. I'm uneasy with that.

OK? Are you also uneasy about mutable strings, or are numbers and
Booleans the only ones?

> > > My point is exactly that comp.prop = should change the value of
> > > prop, which could possibly or not be hold by a model.
> >
> > I just think that Proxies shouldn't have to think about Models at
> > all.
> 
> but that's a not possible ideal.

No it isn't... But in the interest of practicality, it is reasonable
for Components (or Proxies) to react to update events -- and the
assignee protocol releaves the programmer of linking and unlinking
models and Proxies. But I see no need to go beyond this.

[snip]
> > > comp.modify(prop=1)
> >
> > Or
> >
> >   comp.prop.value = 1
> 
> but then one should know that prop is a model, so if one wants to
> write e.g. a model-agnostic handler one should still use the above
> .modify(prop=) idiom.

True. That would also be true for mutable non-model objects that you
want to modify in-place.

[snip]
> > > I think the question is what's the typical operation: changing the
> > > value of a prop, or playing with whether there's a model there.
> >
> > Maybe. I rather think the question is this: If you want to modify a
> > model, would you rebind an attribute of a different object?
> >To modify
> > the object foo (a model) would you find it natural to rebind bar.baz
> > (an attribute of a proxy)?
> 
> yes, if I'm in an handler that should work independently of whether
> a model has
> been installed or not.

I see your point.

[snip]
> > If we start treating models differently, these "dumb models"
> > (modifiable objects that aren't really models) become a grey area.
> > If we keep the existing mechanism, it's all consistent.
> 
> but we already have aggregates that does not have a clear cut
> semantics.

Oh? Which ones?

> And above if lbx.items would be set to a model, we would
> not need the push to make the listbox change.  So they are already
> somehow a grey area.

Maybe.

> At the moment the only kind of mutable value that is relevant for
> our comps is list. And the whole point is whether
> 
> lbx.items = ['foo','bar','baz']
> 
> should have a normal reference semantics or a copy semantics. But I
> should admit that this issue make me less uneasy that the mutable
> "subclasses" of immutable types.

OK.

[snip]
> The .push thing is not so natural either. I would even say that
> listbox.items should always be a model or a normal list can be
> passed to ListBox ctr but then items is immutable...  (that's
> somehow how swing listbox work).

That was one previous version of how things worked (converting to
a tuple).

Hm...

> regards.

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