Re: Empty? No. Array? No. Has? Yes.

[Tim Hill <drtimhill@...>]

On Jul 7, 2013, at 8:54 AM, Luis Carvalho <lexcarvalho@gmail.com> wrote:

You seem to carry some sort of prejudice against the two other solutions,
trying to make them worse in light of your solution. To me, that's what makes
this discussion "tired and frustrating": you pretty much ignore or understate
other people's points and replies for the other two solutions, and does not
offer new arguments for the "empty" value. It's not much of a discussion; it's
more like a reiteration of your points, where the pros are highlighted and the
cons are dismissed. I'm probably missing something here, but I'm failing to
see the need of such a big change for such a simple (initial) problem.

As for prejudice, we all have that. I've only re-iterated when people have asked questions that have already been answered earlier, which I take as an assumption that they did not see the earlier posts. I've followed the other suggestions here with interest, some have been excellent, some I did not think were as workable .. I made that opinion clear in my posts.

My arguments about getter/setter were one of aesthetics really. If 'nil' gets used as a valid element of an array (by whatever means), then you are going to tend to drift towards a model in which 'nil' will get used as "valid" data both as function arguments and return values (getter/setter being the most obvious example). At which point you are going to start colliding with other conventional uses of 'nil', particularly the nil+error return convention that is very common. Of course there are work-arounds to this, such as throwing errors instead, but it seems to me you are starting down a slippery slope of creating a library that, while technically useable, has some very un-Lua-like characteristics, something I don't consider a good idea.

As for what is going to happen here; that's very clear. Nothing. Which is fine, I have a work-around, and shall focus on more productive areas.

--Tim