On Jul 7, 2013, at 8:54 AM, Luis Carvalho <email@example.com> wrote:
You seem to carry some sort of prejudice against the two other solutions,
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.