Re: Models...

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.

> 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. We have a couple of mechanisms (e.g. the Assignee stuff) in place
so that one can implement MVC stuff -- and we provide anygui.Models
with example models for some basic stuff. But basically they are just
glorified values that behave like any other values except that they
can send out events when they are modified.

> 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

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

  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.

[snip]
> > I'm not immediately enthusiastic about this. It's an interesting idea,
> > though -- maybe I just need time to adjust to it :]
> 
> Of course it becomes only necessary with the value-change semantics for
> comp.prop= otherwise we don't need it.

Right.

I still think that models should be a concept extrinsic to proxies.

We *might* perhaps add a registerModel method -- or something -- to
take over the job of the current assignee protocol. But the subsequent
semantics would be the same, i.e. using model.value to modify the
model, not proxy.attrib.

[snip]
> my point was the model to value-type conversion, beyond that the
> conversions are up to wrappers.

I see.

However, if we choose not to give models any special status (i.e.
they're just glorified values) this is less useful.

Also, of someone does

  proxy.text = SomeStringLikeClass('foobar')

I think it should work -- which would still require a call to str() in
the wrapper.

> > > Unrelated:
> > > *) We should check the issue with setX etc and setGeometry and wrapper
> > > subclasses overriding only setGeometry
> >
> > Which issue was this, again?
> 
> that in some backends e.g. the generic CompWrapper defines all setX,setY etc
> and setGeometry but then some subclass (e.g. WindowWrapper) redefine only
> setGeometry or getGeometry and does computations on the values, but if one
> changes only x for example, the inherited setX is called and this does not do
> the right thing.

Hm... Not good.

> I think all this (interaction between setters flavors) is
> undertested.

I agree. There should be a test for each back-end on this -- but, as
always, the GUI aspect makes it difficult.

An alternative is to give strict specifications for how the code
should be written.

Any ideas on how to deal with this?

> > > *) What is the general opinion about aggregates and models
> > > behavior?
> >
> > There are no (front-end) aggregates anymore (we killed them to get
> > rid of the rules engine etc.) -- only aliases. So if you do
> 
> but I can still set comp.geometry and retrieve it, and the splitting
> is done (it seems to me) at wrapper level,

Actually, it isn't (or, at least, shouldn't be); the idea is that
setGeometry (and friends) is defined in Rectangles.py -- and that
Component subclasses Rectangle.

> so I'm not sure what happens if I put a model in comp.x and modify
> comp.geometry ???

Hm. As it stands, comp.x would no longer be bound to the model; but
that's just a flawed implementation in Rectangles.py, I guess.
Replacing self.set(foo=bar) with self.modify(foo=bar) etc. in the
setter methods would make the behaviour more sensible -- don't you
think?

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