Re: 'oldindex' metamethod?

[Udo Schroeter <udo.schroeter@...>]

Let's start with this one:

> The only possible actual
> change I can see that you MIGHT be speculating on (but not actually
> saying anything about) is making the # operator return the number of
> elements in the table rather than the index of the highest element in
> the sequence.

to which I wrote

> implementation detail that bleeds through into userland big time,
> [...] to the way table sizes
> are calculated

You are right I didn't say anything about a possible implementation,
but that's due to the fact that I put forward two separate ideas about
this earlier.

The first was: let's discourage users from messing with the array
part, which includes setting numerical indexes manually and punching
nil holes into the table, but it also pertains to the length operator
returning the number of actual entries. This is what I referred to as
turning arrays into sequences.

I get that you assert the "array part" doesn't exist in the first
place, but this is what I (obviously) don't understand. Because
clearly table entries with numerical indexes are handled differently
from other keys, both behind the scenes AND in the language itself.

The second alternative I was rambling about was to unify the behavior
of the table by making it an ordered hash. This would mean that the
table runtime no longer cares what kind of index an entry has, since
its values wouldn't influence anything except lookup. Of course that
also means keeping an ordering value behind the scenes.

Both ideas, whether they seem attractive to people or not, are clearly
and very obviously different from the way tables work now.

I get the feeling that I failed to express this correctly or at least
in a way that doesn't seem like thoughtless noise :( but I really
tried...



On Thu, Sep 18, 2014 at 4:44 PM, Coda Highland <chighland@gmail.com> wrote:
> On Thu, Sep 18, 2014 at 5:32 AM, Udo Schroeter <udo.schroeter@gmail.com> wrote:
>> It's an implementation detail that bleeds through into userland big time,
>> though. From the pairs()/ipairs() distinction through to the way table sizes
>> are calculated (which I believe was the thing that set off this discussion
>> in the first place).
>>
>> On the one hand I totally understand where the resistance is coming from,
>> but on the other hand it's one of these fundamental decisions that are a big
>> source of WTFs for new users. Of course experienced devs reflexively code
>> around it and never encounter any problems.
>>
>> Personally, my take-away from this when I learned Lua was to just not use
>> numerical indices anywhere - and with iterators that works out just fine.
>> But it's a gotcha.
>>
>> My reason for _not_ keeping these thoughts to myself was the impression that
>> this is a speculative thread, not an actual feature request.
>
> I'm not resisting change. I'm actually not SEEING what's actually
> different between your proposal and reality. The only possible actual
> change I can see that you MIGHT be speculating on (but not actually
> saying anything about) is making the # operator return the number of
> elements in the table rather than the index of the highest element in
> the sequence. The rest... I guess I'm missing something.
>
> /s/ Adam
>