Re: Index with multiple parameters?

[Daniel Stephens <daniel@...>]

Having read through the thread so far I can definitely see the advantage 
for some situations for the existence of some kind of 
assignment-equivalent statement that supports multiple parameters, but 
I'm also convinced that extending [] is the wrong approach, for reasons 
including:

*Incompatibility without massive ugliness with the existing __newindex 
syntax
*Potential breakage of existing code: function x() return 1,2; end 
some_object[x()] = 3;

Ideally there could be a new multi-arg indexing syntax with its own pair 
of metamethods, allowing for both multiple arguments **AND** multiple 
assignments?

Something like:

__setmulti(object, numIndices, ...)

Where matrix[1, 2] = 8.1, 0.0, 7.2;

Becomes

_setmulti(matrix, 2, 1, 2, 8.1, 0.0, 7.2)

What I dont know (since I've not played with any of them) is whether any 
of the existing language extension mechanisms provides the framework 
required for this without modifying the language directly.

Daniel.

Chris wrote:
> On Feb 19, 2008 5:59 PM, Daniel Stephens <daniel@danielstephens.com> wrote:
>   
> > Why does foo need to be a table at all in this example? Why not make it
> > a object with multi-arg get and set methods?
> >
> > You're already signing yourself up for a function to implement the
> > functionality, trying to hide it behind lua syntax doesn't seem like a
> > particularly big win, though perhaps I'm missing something clever?
> >     
>
> foo isn't a table, it's a userdata vector type.  My example was
> probably a bad one too because I'm not attempting multiple depth
> indexing.  A more realistic example would be:
>
> vertex_vector[20, 'x'] = 2.5
>
> My issue is sort of along the same lines as another thread here
> recently talking about high performance math.  The problem is I want
> to use the indexing syntax for readability but at the same time
> prevent creation of millions of temporary objects.
>
> Get/set functions do certainly work but since there will be lots of
> different types of these vectors and this is one of the primary
> interfaces my application uses the code would look horrible and be
> difficult to manage.   I mean technically metamethods aren't needed at
> all but we use them to make the interface better.  I'm just trying to
> make the interface better if it would be a relatively simple patch to
> the parser.
>
> I'm open to ideas of better ways of handling this.  Currently I _am_
> using get/set methods but it's really painful.
>
> CR
>
>