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

[Tim Hill <drtimhill@...>]

On Oct 2, 2013, at 7:59 AM, "Joseph Manning" <manning@cs.ucc.ie> wrote:

> On 2013-Oct-02 (Wed) at 01:27 (-0700), Tim Hill wrote:
> 
>>> I'm stunned that you can seriously suggest
>>> "honors the contract with you to use only sequences".
> 
> Tim,
> 
>   I agree that a fast and easy 'table.issequence( t )' would be
>   very welcome, but if there was a fast and easy way to implement it,
>   I'm sure the Lua developers would have long ago thought of it.

Hmmm, an odd argument, kind of in the class of "this can't be a good idea, because if it was someone else would have thought of it before". I can certainly think of a reasonable way to solve this problem (which requires a slight but subtle change to the definition of "sequence" and would have negligible impact on the Lua implementation) but generally such discussions are frowned upon in this list.

>   For validating its arguments, how far should a function go?
>   At some point, it seems practical or even necessary to trust them.

Agreed, there is always an issue with "how much" validation is enough. Usually, this comes down to an analysis of the consequences of NOT checking some aspect of a parameter. If you don't check for NULL pointers, for example, you risk crashing the app (or OS if you are a driver).

And let's face it, if I had access to table.issequence(), and it was a cheap API, would there be any argument against NOT using it?

function addSeq(t)
	if (type(t) ~= "table") or (not t:issequence()) then error(…) end
...
end

This doesn't seem unreasonable to me.

There is also, of course, the issue of final consequences. Some of the software I design and develop is mission-critical; if it fails unexpectedly people die (really). This leads to a certain level of (healthy) paranoia when writing APIs :)

--Tim