Re: Some metrics on Lua 5.1 -> 5.2 migration

[David Burgess <dburgess@...>]

> 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 <brian.kelley@gmail.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!
>
> -bhk
>



-- 
David Burgess