Re: Need for help

[RLake@...]

> However...
> Once you allow the "index / newindex" metamethods on a global table the
> situation changes. Now assignment IS an operator (some of the time).

Well, that depends on how you look at it. In one sense, = is an operation
when applied to anything other than a local, since it is "syntactic sugar"
for "settable" (whether the table is the "global" table or some specified
table.) But the target of the operation (in the case where it is an
operation) is always the table, never the previous value. Of course, the
table itself can consult the previous value if it wishes to.

Caveats: (1) "table" in the above should be "table or userdata with
metatable". (2) __newindex actually ensures that there is no previous
value. In order to actually consult the "previous value", you need to store
the previous value somewhere else (such as in a proxied table). I think
that this makes it even clear that the target object is consulting its
internal state, rather than a message being sent to some other value.

> Of course the current method works fine for globals & table variables. If
> locals were handled too then things would be complete. :-) So would it be
> worth adding a special type that traps assignments...? I don't know.

I don't see the point in handling locals; I certainly don't want the
overhead (however slight) to be added to every local reference. You can
easily handle this situation by using a local table with a metamethod.

Adding a special type that traps assignments strikes me as a really bad
idea. By the time you got to that point, you would have lost the
information about the container of the object. Consider the case where the
container is actually a userdata with metamethods implemented in C. Now,
what you are asking = to do is to call the __index metamethod of the object
in order to see if the value is a "trigger value", before calling the
__newindex metamethod of the object (or instead of calling the __newindex
metamethod). But what if the object wants to distinguish between "read" and
"write" accesses? Now, it is going to get a "read" access even on "write".
Leaving it up to the object to decide what to do with its members is a much
cleaner approach.

R.