Re: pairs(t, skey) and ipairs(t, skey)

[Sean Conner <sean@...>]

It was thus said that the Great Tim Hill once stated:
> 
> And thus I find it desirable to check to see if an array is well-formed
> before using # .. but there is no way to do this in Lua that is not O(n).
> 
> If this were all my code base, then, as others have suggested, the
> solution is "make sure you don't create ill-formed arrays", but it's NOT
> all my code base and I need to be defensive when writing APIs to be
> consumed by others.

  Users of Lua have to face this at some point, and trying to protect users
from themselves is perhaps not the best use of one's time.  Would it not be
sufficient to say:

	Lua requires arrays to be "well formed" <give definition here>.  If
	an array is not "well formed" unpredictable results can occur.  If,
	on output, you do not get what you expected, it may be that you
	passed in a Lua array that was not "well formed".  If this is the
	case, you may want to call

		super_slow_but_pedantic_well_formness_check() 

	to see if you have have an array that is not "well formed".

  There's a related story (this didn't happen to me) to this:

	http://prog21.dadgum.com/40.html

of the type of thing that can happen if you try to be too defensive [1].  I
will also contend that being too defensive hides bugs [2].

  -spc 

[1]	Yes, the article deals with optimizations, but the connection here
	is "trying to overly protect the user" which sets up a possibly
	unrealistic expectation of the results.

[2]	I got this from _Writing Solid Code_ [3] by Steve Maguire.  Sure,
	it's from Microsoft, but it was one of only two programming books
	that radically changed how I approach programming, and I highly
	recommend it.

[3]	http://www.amazon.com/exec/obidos/ASIN/1556155514/conmanlaborat-20