Re: Deep __newindex on assignment?

[spir <denis.spir@...>]

Javier Guerra dixit:

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

Seems to be the same solution I mentioned in the next point:
* An implementation scheme: look for "value object" design pattern. This implements the trick that a value change always performs & return a copy, instead of changing the value on place. So, you'd always have to write eg:
   pos = pos.change(...)
instead of:
   pos.change(...)
This is called is the Java/C++ world "value object" design pattern.

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

Yes. Both mismatches happen.

My point of view is reversed: in the conceptual model, there are values (data that qualify state/objects: size, color, position, name, phone...) & objects (individual thingies with identity, usually shared: character, weapon, widget...). This conceptual distinction _could_ map to a distinction in programming languages between 2 natures of data types; it is a deeper distinction than ordinary type difference. But I know of no PL implementing this.

On the other hand, most dynamic languages implement the all-reference scheme, but with a secondary difference between mutable/compound & immutable/simple types. The latter can only act _like_ values, even when referenced. In most cases, this scheme will work fine, because simple data often represent values, while compound ones often represent conceptual objects. But each time this // breaks, a trap awaits to catch the programmer. Because there is (what I call) a "semantic distortion(*)". The language doesn't perform anymore do what the programmer expects.

(*) I guess in english "conceptual mismatch" may be a better idiom. Esp. because in computer science "semantic" does not refer to human thought but to machine performance (!).

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

Very clear table, indeed! (is it a shareable one? ;-)

Denis
________________________________

la vita e estrany

http://spir.wikidot.com/