Last modified: 2013-05-14 10:36:24 UTC
Hi! I don't know why gsub is used in function mw.text.trim in mw.text.lua; I would have written that function as following: function mwtext.trim( s, charset ) charset = charset or '\t\r\n\f ' return mw.ustring.match( s, '^[' .. charset .. ']*(.-)[' .. charset .. ']*$' ) end Also I would have made a mw.text.trim using the string library, and a mw.text.utrim using ustring, since it would probably be used most of the time with 1-byte characters...
Forgotten: I would have written "s or ''" in place of simply "s" so it would not fail if given nil.
(In reply to comment #0) > I don't know why gsub is used in function mw.text.trim in mw.text.lua; No particular reason. > I would have written that function as following: Any reason? In some quick testing here, they're both about the same speed (180-200µs each). > Also I would have made a mw.text.trim using the string library, and a > mw.text.utrim using ustring, since it would probably be used most of the time > with 1-byte characters... OTOH, that would require callers to know whether they should call mw.text.trim or mw.text.utrim.
(In reply to comment #2) Thank you for your response! > Any reason? In some quick testing here, they're both about the same speed > (180-200µs each). It is nice then! I was thinking that - having 1 more argument - and replacing the match in the string in place of simply returning it would consume more resources. But it is probably optimised internally by Lua... > > OTOH, that would require callers to know whether they should call > mw.text.trim > or mw.text.utrim. Yes, like they have to choose between string or ustring library
(In reply to comment #3) > (In reply to comment #2) > Thank you for your response! > > Any reason? In some quick testing here, they're both about the same speed > > (180-200µs each). > It is nice then! I was thinking that > - having 1 more argument > - and replacing the match in the string in place of simply returning it > would consume more resources. But it is probably optimised internally by > Lua... Actually, all the replacing logic for mw.ustring in Scribunto is in PHP, which itself uses the PCRE library (in C) to handle most of it. > > OTOH, that would require callers to know whether they should call > > mw.text.trim > > or mw.text.utrim. > Yes, like they have to choose between string or ustring library Which itself is unfortunate. At any rate, it's too late to make this sort of change to mw.text.trim now. But if there is a general need for a faster binary trimming function it would be possible to add mw.text.trimBytes (name to be bikeshedded later).
(In reply to comment #4) Ok, thank you!
