Re: Models...

From: Magnus Lie Hetland <[email protected]>
> Samuele Pedroni <[email protected]>:
> [snip]
> > But models are eminently not values, they are holders.
>
> I guess this is one point where our perspectives differ. I see Models
> as observable objects -- that's it. Model.value is just a basic value
> version of the Model, useful for modifying the Model.

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.

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


> > If I get a component and want to change a boolean property without
> > throwing away a model that the surrounding context could have placed
> > in there, I should always write
> >
> > 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.


> which would be the preferred idiom, *if* you do want to modify it
> directly like this. I think earlier discussion indicated that it would
> probably most often be modified elsewhere -- i.e. if
>
>   comp.prop is model
>
> then you would use
>
>   model.value = 1
>
> somewhere else in the code.
>
> > comp.prop=1 would discard the model.
>
> Indeed. I think this is perfectly consistent with ordinary Python
> attribute syntax. If you rebind an attribute, you lose the original
> reference.


> > 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 think it would be more natural to rebind
> foo.value, or perhaps assign to foo[42], or something else altogether,
> i.e. modifying the model directly. If bar.baz happens to be bound to
> the model, you could certainly assign to bar.baz[42], or rebind
> bar.baz.value -- but rebinding bar.baz itself should not, in my
> opinion, modify the model.
>
> The only difference between a model and another mutable value is that
> models send update events. So you could just as well do something like

but we have models for typically immutable values, honestly is a trade-off
between that and a not totally reference-rebinding semantics for comp.value= .


>   lbx.items = items = ['foo', 'bar', 'baz']
>   items[1] = 'fnord'
>   lbx.push('items')
>
> 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.
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.

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.

Interestingly for this case the only form of model-agnostic code one can write
is

lbx.items.op(...) # e.g. insert()
lbx.push('items') # not needed if items is a model
...

[Btw some backends have a getItems, that means that with the current CVS (dunno
with Dallas's code) a
lbx.items
would substitute items behind the scene.]

For full disclosure I should admit that in Jython we already have situations
where javaobj.prop= [...] have a copy semantics, that's probably why I can live
with that.

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

regards.



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