[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Some metrics on Lua 5.1 -> 5.2 migration
- From: David Burgess <dburgess@...>
- Date: Mon, 15 Apr 2013 12:43:02 +1000
> string.match(str, pat, init) === string.match(str:sub(init), pat);
That is definitely intuitive behaviour.
On Mon, Apr 15, 2013 at 10:39 AM, Brian Kelley <email@example.com> wrote:
> I haven't seen any quantitative assessments of the cost of moving to Lua 5.2
> from 5.1, but I thought someone might be curious, so I collected some stats
> while migrating a code base recently.
> 29,300 lines of Lua
> 10,400 lines of those are unit tests
> Issues encountered:
> 30: unpack --> table.unpack
> 9: loadstring --> load
> 5: pairs ordering assumption
> 5: loadstring + setfenv --> load
> 3: loadfile + setfenv --> loadfile
> 3: maxn
> 2: require "debug"
> 1: gsub invalid "%" in replacement string
> 1: os.execute
> 1: setfenv (avoidable)
> 1: match past end of string
> 1: package.loaders --> package.searchers
> Most of these are well documented, but a couple of notes are warranted:
> 1. The "match past end of string" issue refers to string.find or
> string.match behaving differently when the "init" argument is beyond the end
> of the string. Previously, it would match patterns that would match an
> empty string. Now it returns nil. [FWIW, I prefer the previous behavior,
> because (a) it preserves this intuitive relation: string.match(str, pat,
> init) === string.match(str:sub(init), pat); (b) a general backwards
> compatibility bias, and (c) the change slightly complicates my code in this
> case. ]
> 2. The "pairs ordering assumption" issues refer to cases where the code made
> assumptions about the ordering of keys returned from pairs(). For this code
> base, these assumptions were made only in the test cases (fortunately), but
> I wrote an "opairs" ("ordered pairs") alternative to "pairs" for usage in
> cases like serialization where the ordering becomes observable to clients.
> Some subjective comments: Lua 5.2 is clearly a step forward, and the code
> has improved where it has changed. We have always avoided module() (and
> most globals for that matter) so that was not an issue in this case.
> Abolishing setfenv() and getfenv() makes sandboxing cleaner and easier. I
> look forward to a future Lua that abandons globals completely in favor of
> manifest upvalues!