Re: what to make of this fellow named __ipairs?

[joao lobato <btnfdp.lobato@...>]

On 1/27/11, E. Toernig <froese@gmx.de> wrote:
> Tony Finch wrote:
>>
>> One of the significant oddities in Lua is the distinction between methods
>> called using the : operator and metamethods called by the language runtime
>> and some library functions.
>
> Indeed.
>
>> However I don't think it can keep backwards compatibility without
>> sacrificing efficiency. The key change is a version of the old idea of
>> making the lookup algorithm for : different from . which allows more
>> natural support for class-style OOP by making it easy to separate instance
>> variables from methods.
>
> Not only instance variables, data too (if the instance is the container
> for arbitrary data).
>
> I'm advocating for a change to the colon operator for nearly 10 years[1]
> and I've given up by now.
>
> Ciao, ET.
>
> [1] i.e. http://lua-users.org/lists/lua-l/2001-11/msg00459.html
>
>

What about the case when wants to discover the method name at runtime:

instance:method(args) -- okay, __method

local someMethod = 'method'
instance[someMethod](instance,args) -- __index or __method?

Tables are associative arrays with a few tricks to allow them to serve
has building blocks:
 - the dot syntax allows them to look like structs or namespaces (but
fails on the infamous bit.and);
 - the colon syntax allows them to look like objects (but fails on the
reflection example);
 - the {1,2,3} constructor, # and the underlying "implementation
detail" allow them to look like arrays (but fail regarding nil - which
was always meant to be a "non value" anyway);
 - __pairs and __ipairs exist only to make them better (more
transparent) proxies (but apparently __next is missing);
 - __call allows them to be... functors?

In a way, Lua as a whole follows the same principle as its tables:
it's a clean and enjoyable imperative language with a side of:
 - data description language (tables again :));
 - full-featured functional language;
 - pretty nice OOP language (class or prototype, you choose);

In the end, those metamethods are a distinguishing feature while
method calling through : is syntactic sugar.

I guess I got a bit philosophical, my point is that, in my opinion, if
one mixes container data with methods, it looks like bad design.