[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Empty? No. Array? No. Has? Yes.
- From: Andrew Starks <andrew.starks@...>
- Date: Sun, 7 Jul 2013 15:16:31 -0500
On Sunday, July 7, 2013, Tim Hill 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.
In the context of these comments, I wonder what your thought on my proposed use of rawset and rawset, which, and I have to look this up to be sure, I believe are a pair of "setter" and "getter" functions. :)
nil is a "thing" everywhere in Lua. So, using it as "empty" makes a great deal of sense. It's actually a reasonable synonym for the word. In fact, I believe that it gives it one meaning where once there might have been two: "don't put this key here", and "set this key to nil."
If nil is un-special in the context of an array (as defined as one with possible nil values in it) and the end of said array is specified as, "The first index with no value, where select('#', rawget(t, i)) == 0)"
Then, delete could be defined as:
rawset(self, i) --not rawset(self, i, nil )
A non-optimized length would be:
__len = function(t)
local i = 1
while select('#', rawget(t, i)) == 1 do
i == i + 1
return i - 1
in this array, `t[#t] = nil` would mean exactly that, where in a Lua sequence it would mean "pop the value."
To my thinking, this approach removes a special optimization in favor of simplifying nil's meaning.