 |
lua-l archive |
|
|
||
|
On 10/04/2011 0.33, Sean Conner wrote: [snip]
It's easy enough to fix in stock Lua:
do
local tablesort = table.sort
function table.sort(t)
tablesort(t)
return t
end
end
Anyway I was just arguing that adding that behaviour to stock Lua would make the API a bit more convenient without forfeiting anything (Am I wrong here?).
Maybe it could help make the code clearer, since often sorting an array is just an intermediate step of some other operation. _Always_ forcing the use of a temporary, especially when there are several arrays to be sorted in the same region of code, could increase the confusion sometimes (it could even make certain optimizations hard, if I remember some remarks by Mike Pall in some LuaJit threads - but I may be completely wrong here, since I don't use LuaJit and only skimmed over those posts).
The argument of Luiz, while in general is really sound (especially on very fat APIs with both kind of functionalities: in-place modification vs. return a copy), doesn't convince me too much in the specific case, since there is no uniformity to be preserved/enforced in the current API: table.sort is almost a "lone beast" (and quite a well behaved one, compared to other API functions - see the recent threads on table.insert, etc., etc.) - I don't think stressing the "in-place" behaviour in this way really makes a difference.
After all there are APIs - even in other languages - in which returning the just modified argument to allow "chained" calls is the default. So I think it is really a matter of personal habits and conventions restricted to specific APIs. But here we would need a survey to check how many programmers find the absence of a return value so useful as a way to avoid errors or increase readability in using table.sort :-)
-spc
cheers -- Lorenzo