Re: Deep __newindex on assignment?

[Javier Guerra <javier@...>]

On Wed, Dec 23, 2009 at 8:11 AM, spir <denis.spir@free.fr> wrote:
> * A difference in assignments of the form "x=y": in case y is an object, only its reference is passed by; in case of a value, a copy is performed.


this seems to resume the issue at hand.   i think the shortcomings, or
rather, "behaviour surprises" come because of this difference.  the
common example mentioned here boils down to the need to have some
"compound value" with more 'value-like' semantics, and not the
'reference' issues, especially the non-desirability of sharing a table
between objects (which makes those objects related in sneaky ways).

what has helped me in some occasions is to predefine the model i want
for the problem at hand, and consistently implement it; not
(necessarily) hoping the language fits the problem.

what does that mean for the current issue?  it gets down to mutability
vs. immutability for 'higher level' objects.

in the "point that has a position field" example, you'd like the
'position' object to behave as a compound value, with immutability
semantics.  i can think of two approaches to that:  a) never modify
the position object in-place; replace any change operation by the
creation of a new object. b) don't use the position object passed by
the user; use a copy instead (breaking any possible object-sharing).

the other possible mismatch is the converse one: you need to share a
single value between two different object, so that when one is
changed, the other one 'sees' the same change.  in this case, you have
to wrap that single object in a table, and reference that same table
several times.

resuming: the decision tree for implementation looks like this:
- this 'thing' here is simple? or complex?
- i want it to be immutable/non-shareable or mutable/shareable?

the answer to these two questions determine if you have a match or
mismatch between your needs and what Lua provides:

* simple immutable: (match) use a simple value (number, string)
* simple mutable/shareable: (mismatch) use a table to hold a single value
* complex immutable: (mismatch) use a table, copy at specific points
(either at creation or at any modification)
* complex mutable/shareable: (match) use a table, share at will

hope this helps

-- 
Javier