Re: New metamethod for method lookup

[Jerome Vuarand <jerome.vuarand@...>]

2009/11/15 Mark Hamburg <mark@grubmah.com>:
> Arguments against:
>
> * It's an addition. (The default position should generally be to say "no".)

Not only an addition, but a mere syntax addition. The code behind the
new syntax can already be written with current Lua, the added value is
nothing compared to for example tail calls or userdata environments,
which are real features.

Also sometimes people are confused by the dual aspect of table (ie.
array and dictionary). This would add a third aspect to tables.

Finally the proposal would break the fact that the colon syntax is a
mere syntactic sugar. The beauty of Lua is that if you remove its few
syntactic sugars, the core of the language is very simple, and can be
truly mastered by normal people (as opposed to C, Javascript, or even
Python). Adding yet another metamethod for an already defined
behaviour (personnaly I'd ditch index and newindex on tables, and
officialize newproxy instead), or another indirection level when a
table value is nil, is just adding unnecessary complexity.

> * The semantics still need work. (Or at least say "not yet".)
>
> Arguments in favor:
>
> * It simplifies the implementation of objects with both methods and properties allowing method lookup to bypass a function call. (There was an alternate proposal a while back, I believe to allow a metatable entry that had to be a table and a fallback function beyond that.)
>
> * It makes it possible to guarantee that methods are only invoked with their associated objects thereby avoiding certain bugs and/or security holes and/or the need for extra type-checking. This thereby also potentially speeds methods. For example, userdata methods using a __methindex table for exposing methods could safely access their data via:
>
>        native_type* self = (native_type*) lua_touserdata( L, 1 );
>
> * On a related note, it means that accidental uses of obj.method() instead of obj:method() will generally result in an error at the call site rather than further on when something is unhappy about the value of self.
>
> Depending on the semantics chosen, it may or may not help with the case where there needs to be an overlap between the method namespace and the index namespace (e.g., for the Set class). (Another name for this proposal could be "separate namespaces for methods and keys" which feels odd to advocate for since I've long preferred LISP-1s to LISP-2s but the case here is a bit different.)
>
> Mark
>
>