 |
lua-l archive |
|
|
||
|
On Dec 18, 2008, at 2:01 PM, Matthew Wild wrote:
I'm probably missing something, but why use this method and not closures? That is, why not define "angle" and "radius" as upvalues, along with "self"?
That works but it makes objects very heavyweight (you need new closures for every method and new upvalue cells for every data entry) and doesn't play as nicely with __index-based inheritance. It also doesn't match with the style encourage by mechanisms such as the colon operator which is to use tables as objects. It's nice that Lua allows for other approaches, but it is also clear what the primary paradigm is.
Tables as objects work perfectly well from an encapsulation standpoint until someone uses pairs on them to discover the hidden keys. The ability to override pairs is insufficient to guard against this as long as next remains available. But part of my proposal basically just called for formalizing a mechanism for creating non-iterable keys. The remaining portion had to do with syntactic constructs to make it more natural to use these hidden keys. I've seen lots of inefficient, awkward to maintain code that strives for achieving encapsulation in objects handed across interfaces. What has struck me about that code is that really all you need are two things:
1. Keys that can't be synthesized -- i.e., something other than strings; and
2. A way to keep those keys from being discovered via iterationFinally, I note that no one has commented on the first portion of my proposal which was to support obj:[ message_expr ]( ... ) as a way to send a message that gets determined at runtime. I think that the SELF opcode is even already compatible with this.
Mark