Re: sunday afternoon whishlist

[HyperHacker <hyperhacker@...>]

On Mon, May 10, 2010 at 09:33, Quae Quack <quae@daurnimator.com> wrote:
> On 10 May 2010 16:26, Juris Kalnins <juris@mt.lv> wrote:
>> Actually, it would be more powerful to have [] operator take arbitrary
>> number of
>> values, just like () does.
>> Then:
>> x.y.z --> x[y,z] --> x_metatable.__index(x,y,z)
>> x.y.z = v --> x[y,z] = v --> x_metatable.__newindex(x,y,z,v)
>> x[] --> x_metatable.__index(x)
>> etc.
>>
>> And have default behavior forward indexing calls to nested
>> elements, just like it works now.
>>
>> This would allow a simple way to implement things in the wishlist,
>> plus simplify many cases that currently require use of proxy objects.
>>
>
> That is a very cute idea actually, and is something I wouldn't mind seeing.
> As mentioned, this would make matrix operations so much more easier,
> as well as opening up a whole new class of cool things to do..
> Its seems to be quite backwards compatable, only changing what is
> passed to __index and __newindex...
> Can anyone come up with any issues?
>
> Daurn.
>

An obvious one I see is what happens when you do this?
t = {}
t[1,2] = 42
t[1,2] = 27
On line 2 it's going to pass two parameters to __index, but on line
three, unless a __usedindex or some such method is added (which I
highly support and have already patched into my own copy), where do
the multiple parameters go?

As for t[], my vote would be
t[] = x  =>  table.insert(t, x)
x = t[]  =>  x = table.remove(t)

I actually think next(t) would be better for the latter (so repeated
reads of t[] return each element without removing it), but that would
require storing the index somewhere internally and incrementing it
each time. Perhaps it can be stored in the metatable, and/or this
syntax can call __index(t, nil) and let the index method deal with
keeping track.

-- 
Sent from my toaster.