lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> Date: Mon, 25 Nov 2013 20:03:37 +0000
> From: Kevin Martin <>
> Subject: Re: table library changes (was Re: in 5.3?)
> Maybe ipairs would be redundant with your iterator patch (which
> admittedly I haven't looked at), but in standard Lua, I definitely
> think it fulfils a role over for i=1,#t
> > These are certainly good cases for specialised iterators, but why
> implement them by hijacking 'ipairs'? Again, write your own iterator
> factory and call it something appropriate.
> Because in standard Lua, I don't have your patch, but I do have ipairs.
> I'm not saying that ipairs is the best solution, only that in standard
> Lua, without your patch, it is not redundant.
> However, this message has been the kick I need and when I have some
> time available, I will be giving some of the power patches a go.

Thanks, Kevin,

Deprecating 'ipairs' would *help* the case for the approach in the self-iterating objects powerpatch (because the main argument against it is that it forces a choice per metatable between 'pairs' and 'ipairs' or something else you write yourself), but I do not agree that there is any dependency the other way.

I see the need for *one* privileged iterator ('pairs', or more specifically, 'next', needs C support). I accept the argument for supporting *many* iterators with mechanisms for writing your own. What I don't buy is the case for *two* privileged iterators (Lua privileges 'ipairs' by having it in the standard library and by having a reserved metamethod to override it).

My approach would be to remove 'ipairs' (and some other cruft which can be written nearly as efficiently in Lua) from the standard (C) libraries, and then add them back as optional compatibility libraries written in Lua. I don't want to *ban* 'ipairs', just to stop *privileging* it!

Best regards, John.

This email is free from viruses and malware because avast! Antivirus protection is active.