RE: settable

[Benoit Germain <bgermain@...>]

I see 3 different events here:

1- trying to get the value of a field that does not exist
2- trying to create a new field
3- trying to change the value of an existing field

As you say, 1 is equivalent for tables and userdata: unifying
__gettable/__index into __getfield is a good idea.
Event 2 has significance for both userdata and tables as well(just like
event #1): this is a __newfield event.
For a userdata, event 3 is irrelevant, because there are no fields: this is
a specific __setfield event.

One might want to capture separately the creation of a new field in a table,
and the modification of an existing field in the same table. This can be
done either by creating two events, or by having a single event and passing
the previous value to the handler along with the table and the key: if nil,
this is a creation, else a modification. 
Obviously, the handler of __setfield for a userdata does not need the
field's "previous value", because there is none: only the userdata and the
key are needed, just as before.

I got a look at the settable semantics, and it looks like field replacement
in a table currently has no associated event. Is this because nobody felt
the need so far, or for performance reasons to avoid a handler lookup each
time a field is set into a table (either __newfield when the previous value
is nil, or __setfield when it is not) ?

Cheers,

Benoit.

> -----Original Message-----
> From: Roberto Ierusalimschy [mailto:roberto@inf.puc-rio.br]
> Sent: vendredi 13 septembre 2002 16:52
> To: Multiple recipients of list
> Subject: Re: settable 
> 
> 
> Maybe we should "unify" the names __index/__gettable (and
> __newindex/__settable). We may think that __index is called when a[i]
> "fails": for a table, a[i] fails when the table doesn't have that key;
> for a userdata, it always fails...
> 
> -- Roberto
>