lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

2013/7/1 Tim Hill <>:
> I would say that from a CS perspective, table.has() and an "empty" sentinel are the same thing in different form; both introduce an extra bit of information about an element in the table, since you now have two possibilities when faced with t[k] = nil: one with table.has() true, one with table.has() false. Logically you could define:
> function empty(t, k) return t[k] == nil and table.has(t,k) end
> --Tim

The difference that matters to me considering your feature wish is,
that no additional value type that can be (ab-)used is required for
the proposal that I made, while still achieving a compatible solution
since you can then explicitly demand the existence of a nil value in a
table and have nils in arrays.
Because if a value does exists, it can also be nil, if it doesn't
exist, it's still nil but you can check that. You can of course not
pass "empty" to a function this way, which your idea allows, but that
can get easily around this if required through additional parameters
or functions in the API that you define yourself.

In my opinion, it is less intrusive than your proposal because it
doesn't add something completely new but changes the behavior of
something old that might make things more consistent - though I am not
the one to judge that in the end, I think that my proposal is in fact
making things more consistent. The behavior of the length operator is
something that I believe no one is truly happy about... and that is
what my suggestion would at least improve a bit. (Of course you can
still argue that this can also be achieved with a new empty type - as
you have shown, it can be emulated with empty but as many here argue,
at a cost of introducing a new value that many appear not to be happy
with for (in my opinion valid) reasons that have already been
discussed in great length)

Cheers & good night,