Re: Slicing ideas

[Rob Kendrick <rjek@...>]

On Mon, Apr 02, 2012 at 04:41:10AM -0600, Rena wrote:
> On Mon, Apr 2, 2012 at 04:35, Rob Kendrick <rjek@rjek.com> wrote:
> > On Mon, Apr 02, 2012 at 12:27:53PM +0200, steve donovan wrote:
> >> On Mon, Apr 2, 2012 at 12:19 PM, Rob Kendrick <rjek@rjek.com> wrote:
> >> > t[1, 2, 3] is to  __slice(t, 1, 2, 3) as t[1] is to __index(t, 1).  ie, a metamethod.
> >>
> >> Cool, now I get it.  And in the presence of __slice, does t[1] resolve
> >> to __slice(t,1)?
> >
> > We'd not thought about it, but my initial feeling is "no", as it would
> > require two table lookups to decide which to call, rather than one.
> 
> Can we do something crazy like t['woah', {}, false] ?

Yes.

> Personally I always thought __index and __newindex should just be able
> to take multiple inputs (using this syntax) and return multiple
> values, but apparently that requires some changes... and my first
> instinct seeing t[x,y] would be that it's 2D indexing, not slicing,
> but with metamethods you can make it work that way anyway.

There are some issues with reusing them like this, beyond compatibility.
Certainly for __newindex/__newsplice, you want things delivered in a
different order to be useful.  Also, it's important for runtime errors
to occur if you try to use multiple values in the dereference with code
that is not expecting it, rather than silent confusion.

But yes, you could make the metamethod do whatever you liked.  The
choice of , was arbitary.  It could have easilly been colon.  For
example, we could make these have identical syntatical meaning:
	t[1, 2, 3]
	t[1:2:3]
meaning you could choose whichever made more logical sense.

B.