lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Am 01.05.2014 23:07 schröbte Eduardo Ochs:
I am afraid that this post may sound a bit rude - so apologies in
advance...

The semantics of "a:b(c)" is already defined, and in a way that is not
going to change; and at present an "a:b" without the "(...)"
afterwards just raises a syntax error.

People are now discussing, for the n-th time, a FIXED semantics for
"a:b" without the "(...)" - as if there could be an agreement!...

It's only three people who have to agree on a proposal (at most, I actually don't know how disagreements are resolved in the PUC-Rio Lua team). (And as Thomas has said repeatedly his recent activity is not meant as a change proposal for Lua ...)


Wouldn't it be much more Lua-ish to just create a new metamethod for
that? Here's how it would work. The current behavior of "a:b(c)" would
not be changed at all, and in all situations where "a:b" currently
raises a syntax error - including "(a:b)(c)" - Lua would instead
generate code that would look for a metamethod "__colon" in the
metatable of a; when that metamethod is found, the result of "a:b"
would be this,

   getmetatable(a).__colon("b")

and when a doesn't have a metatable, or when a has a metatable but it
doesn't have a "__colon" field, Lua would just raise an error: "Colon
behavior not defined for <a>" - or it would look for a default action
in a global variable whose name we would have to decide - "__colon",
maybe?

IMHO, the `__colon` field per metatable would be confusing, because an object from one module would behave differently than an object from the next module, and you would need to keep track of where an object came from. So far the semantics of metamethods are more or less fixed, and the backends/implementations differ. This would be the other way around. I don't think it would be beneficial if *all* colon proposals so far actually ended up in Lua code ... On the other hand, the global `__colon` setting would just cause conflicts like all other shared global settings, e.g. metatables for `_G`, metatables for non-userdata/-table types, etc. So, my opinion is: As long as it isn't clear how it should be done, it shouldn't be done at all! It's not an essential feature after all. Maybe things will become clearer when Thomas has tested his patch in some real-world situations.


Btw, here is a related idea (that got no responses):
   "Re: Multiple indexing (was: 'in' keyword today)"
   http://lua-users.org/lists/lua-l/2014-04/msg00544.html

I not sure the extra metamethods are necessary (and I find them sort of ugly) as long as `__index` always returns exactly one value (the extra arguments to `__index` probably wouldn't hurt even if you didn't expect them). This would allow matrix-like indexing, but not getting multiple values from a single table in one go (as was the intended use case in the thread you linked). Making `__index` return a variable number of return values is more of a breaking change (and for plain tables I _still_ would only return one value by default), but IMHO better than two metamethods that basically do the same thing. For now I will go with: As long as it isn't clear ..., and implement multi-indexing as functions[1].


and here's a link to some recent messages on ":" (april 2014 only):
   "Ideas about colon operator syntax (and a patch in the work)"
   http://lua-users.org/lists/lua-l/2014-04/threads.html#01318

Cheers,
   Eduardo Ochs


Philipp


  [1]: https://github.com/siffiejoe/lua-multikey