Re: Functional objects

[Rici Lake <lua@...>]

On 22-Sep-04, at 12:33 AM, Mark Hamburg wrote:

> PiL finishes the chapter on object-oriented programming with the rather
> Scheme-like approach of implementing objects as function closures. 
> Would it
> make sense to define obj:msg( ... ) as meaning obj( "msg", ... ) if 
> obj were
> a function? This has the downside of meaning that the syntax is no 
> longer
> simply sugar, but it had already ceased to be treated as such in the
> implementation.

Now that I've thought about this since the first time you suggested it, 
it seems more reasonable to me. I find it particularly attractive for 
the case where obj is a coroutine.

To answer Alex's concern (and the second part of the suggestion which I 
think is unworkable), the compiler does not need to know what type of 
object is being self-called, because it simply injects a self call 
opcode, which causes the VM to turn (object, method) into 
(object[method], object). A very simple change to that opcode would 
handle the case where object was a function (i.e., do nothing instead 
of reporting an error).

However, it does create an ambiguity in the case where object is either 
a table with a __call metamethod or a userdata with both __call and 
__index metamethods. Perhaps this is not serious: this could be dealt 
with by simply documenting that gettable (if it exists) takes priority, 
even if it fails to find the key.

Rici