RE: settable

[Benoit Germain <bgermain@...>]

Yes I forgot that one :-). Why not imagine that what is stored in the field
is the name of some resource, and the event would fetch the resource itself
(in case we don't want the resource to be locked as long as it is
referenced, for example).

Another point for the unification:

Consider a function that builds a metatable to associate to some argument A
it receives. This metatable is meant to setup default fields for A. If A is
a table, the fields must be provided by the __index member of the metatable.
If A is a heavy userdata, the fields must be provided by the __gettable
member of the metatable. Of course my function can check for A's type and
build the metatable accordingly, but it would be more elegant if it hadn't
to.

Cheers,

Benoit.

> -----Original Message-----
> From: Björn De Meyer [mailto:bjorn.demeyer@pandora.be]
> Sent: vendredi 13 septembre 2002 19:24
> To: Multiple recipients of list
> Subject: Re: settable
> 
> 
> Benoit Germain wrote:
> > 
> > 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
> 
> And what about 4 - trying to read the value of an existing field?
> Don't we need an event for that? 
> /snip
> 
> However, I agree with Roberto's idea. Frankly, I
> think the difference between a table and a 
> heavyweight userdata should be minimal in
> all aspects, for orthogonality's sake.
> 
> -- 
> "No one knows true heroes, for they speak not of their greatness." -- 
> Daniel Remar.
> Björn De Meyer 
> bjorn.demeyer@pandora.be
>