Re: Why coroutine can't be indexed?

[Eike Decker <zet23t@...>]

2011/7/10 Lorenzo Donati <lorenzodonatibz@interfree.it>:
> On 09/07/2011 18.20, HyperHacker wrote:
>>
>> On Sat, Jul 9, 2011 at 10:14, Dirk Laurie<dpl@sun.ac.za>  wrote:
>>>
>>> On Sat, Jul 09, 2011 at 05:38:59PM +0200, HyperHacker wrote:
>>>>
>>>> On Sat, Jul 9, 2011 at 09:33, Dirk Laurie<dpl@sun.ac.za>  wrote:
>>>>>
>>>>> On Sat, Jul 09, 2011 at 04:58:10PM +0200, HyperHacker wrote:
>>>>>>
>>>>>> That one can easily do it with a metatable especially
>>>>>> makes me wonder why it isn't done by the library itself
>>>>>
>>>>> If this argument were valid for coroutines, it would apply equally
>>>>> to tables:  why must one say table.insert(list,item) instead of just
>>>>> list:insert(item)?
>>>>>
>>>>> To answer your question: it is not done by the library itself
>>>>> _because_ one can easily do it with a metatable.
>>>>>
>>>>> "Less is more" — Mies van der Rohe (1886–1969), architect.
>>>>>
>>>>> Dirk
>>>>>
>>>>>
>>>>
>>>> I'm pretty sure it's not done with tables because list:insert(item)
>>>> already has a different meaning (to look up 'insert' in the table
>>>> 'list'), and to set up a metatable like that could be confusing. (Why
>>>> t:insert() doesn't work? Oh, because t has a key named 'insert'
>>>> already... now is t2.insert a key in t2 or in table? etc)
>>>>
>>> Sorry, I did not absorb your whole post when writing the reply
>>> above.  Tables are indeed different in an important way.
>>>
>>> The interesting question to me is, since it is so easy to say
>>> debug.setmetatable('',{__index=string}), why the equivalent of that
>>> has been built in.  There must have been a debate on that a few
>>> years ago: could an old-timer tell us the clinching reason?
>>>
>>> Dirk
>>>
>>>
>>>
>>
>> That's a big part of my confusion too: why this is built in for one
>> type but not another...
>>
> Just my 2 eurocent:
>
> Lua tend to be simple, so no metatable trickery by default. Especially for
> tables, since _each_ table can have its own metatable.
>
> Moreover tables are the only type for which metatable trickery is favoured
> on Lua side (for other types you have to resort to debug.metatable) and
> providing a default, common, metatable for every table would be a big hassle
> for client code.
>
> I think that string is an exception only because string functions are *so*
> commonly used that that was a sort of compromise for the sake of
> convenience.
>
> BTW, I've seen lot of Lua code where the OOP style for strings is not used,
> i.e.: string.match(s, pattern) instead of s:match(pattern), so it's
> something pertaining to own's programming style.
>
> Cheers.
> -- Lorenzo
>
>
>
>

Actually, I've been wondering myself why co:status() doesn't work. I
would be a bit more convenient, like it is for strings. About
simplicity: Creating such a metatable for coroutines is just a matter
of a few lines of code in C.
But actually, coroutines are not the only case: Numbers, boolean and
the nil lack a metatable as well. It would be sort-of nice if one
could write (3*1.5):floor(). For boolean and nil I can only think of
one useful function and that would be :tostring.
It might be the case that the unification of type-behavior could
simplify code in other parts of the VM. It's questionable though if it
would come cost free in terms of execution speed (I'd guess not, but
you never know...). The only remaining type  that would then lack a
metatable would be the table type itself - And maybe, that could also
be changed so that everything behaves the same ...
Note: Of course, values wouldn't allow individual metatables but would
share instead all the same metatable...

Cheers,
Eike