lua-users home
lua-l archive

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


Klaus Ripke wrote:
> On Sat, Jan 09, 2010 at 12:52:33PM +0300, Alexander Gladysh wrote:
>> On Sat, Jan 9, 2010 at 12:37, steve donovan <steve.j.donovan@gmail.com> wrote:
>>> 2010/1/9 Ignacio Burgueño <ignaciob@inconcertcc.com>:
>>>>> 17. Documented behaviour of ipairs() is changed from "iterates until
>>>>> *first nil*" to "traverses table length elements as defined by length
>>>>> operator".

> I fail to see how breaking perfectly valid code
> by trading a well defined behaviour for all tables
> for something undefined on "arrays with holes" does any good.

Agreed. The only reason #t has its undefined behavior is because it is
impractical for it to iterate the table. But the whole point of ipairs()
is to iterate the table - it is already doing that! So I prefer the
previous behavior - iterate until nil.

Now if there were a clever way to modify the length operator so that the
two methods were the same, that would be the ultimate solution. I can't
see any easy method, though. The best one I have come up with is to keep
upper and lower bounds on #t as nils are set and unset, then
recalculating the length on the next #t usage. It can be made to work,
but the expense is too high. #t is intended for normal arrays (or for
LPEG, or for vector magnitudes, or... that's another thread entirely!).

Doug


______________________________________________________________________________________
The information contained in this email transmission may contain proprietary and business 
sensitive information.  If you are not the intended recipient, you are hereby notified that 
any review, dissemination, distribution or duplication of this communication is strictly 
prohibited.  Unauthorized interception of this e-mail is a violation of law.  If you are not 
the intended recipient, please contact the sender by reply email and immediately destroy all 
copies of the original message.

Any technical data and/or information provided with or in this email may be subject to U.S. 
export controls law.  Export, diversion or disclosure contrary to U.S. law is prohibited.  
Such technical data or information is not to be exported from the U.S. or given to any foreign
person in the U.S. without prior written authorization of Elbit Systems of America and the 
appropriate U.S. Government agency.