Re: '__iter', yet again!

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

2009/12/16 Francesco Abbate <gslshell@gmail.com>:
> 2009/12/16 Jerome Vuarand <jerome.vuarand@gmail.com>:
>> 2009/12/16 John Hind <john.hind@zen.co.uk>:
>>> I really cannot see why this solution is resisted – it is fully backward
>>> compatible and syntactically uncomplicated. The context of the explist is
>>> easily distinguishable being bracketed by the reserved words ‘in’ and ‘do’.
>>
>> The beauty of the language, is that it has very few concepts, used in
>> many places. Rather than having a specific mechanism to iterate over
>> objects, the for loop use the mechanisms of multiple return values and
>> first class functions. The resistance comes from the fact that you
>> want to make Lua more complicated, just to save an explicit method
>> call. And that's assuming that the implicit __iter is better syntax
>> than an explicit method, which is arguable (e.g. I would disagree with
>> you). And concise and cryptic syntax overriding isn't even part of OO,
>> it's just often bundled with it.
>
> I agree with you that having few simple concepts to describe the
> language is a very important benefit. This is also the reason why,
> personally, I like the C programming language: a few pervasive
> concepts and everything else is left to the programmer.
>
> But there is an error in your arguments because the '__iter'
> metamethods does not add a new concept to the language. The feature is
> already there and is the metamethods mechanism itself. We are just
> talking about adding a new metamethod category to handle iterations
> over objects.
>
> When you write:
>
> obj[key] = value
>
> and you call secretly the '__newindex'  metamethods, this is *exactly
> the same* logic of calling __iter in the construct:
>
> for val in obj do

This argument is debatable, especially since you take __newindex as an
example. The metamethod mechanism is essentially a mean to define
undefined behavior, and this is true for all metamethods with two
exceptions: index and newindex on tables (and only that type).

People tend to see metamethods as an overloading mechanism, which they
are mostly not.

For the moment, the for loop does something very simple and precise,
it takes a function and some values, and call that function repeatedly
with some of those values. Introducing a new step in that algorithm
makes things more complicated. Not only do you add the step, you have
to document it and you have to expect for people to ask for a way to
have the previous behavior that ignored the metamethod (without the
exception of index/newindex on tables, we wouldn't need
rawget/rawset).

> Namely, a language construct that is overloaded with object behaviour
> by using metamethods.
>
> For the other side I think that the __call metamethod is weird because
> the calling of a function is such a fundamental construct that
> overloading it can be confusing when you read the code. For the other
> side is can always choose to not overload __call if you prefer so.

You cannot overload __call on functions, only on object that are not callable.

IMHO all these requests for new exceptional metamethods would be
settled if the "index/newindex on tables" exception was removed. This
is only necessary as tables are currently the only way to implement
object in pure Lua. An officialization of newproxy would solve that.