[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Functional objects
- From: Rici Lake <lua@...>
- Date: Wed, 22 Sep 2004 13:33:32 -0500
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.
make sense to define obj:msg( ... ) as meaning obj( "msg", ... ) if
a function? This has the downside of meaning that the syntax is no
simply sugar, but it had already ceased to be treated as such in the
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.