[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: new string functions (was Re: Standard Libraries....)
- From: Majic <majic.one@...>
- Date: Mon, 18 Jan 2010 22:45:20 -0800
I guess it's more a fret over what the functions appear to mean at a
glance if you're used to [brazenly] picking up an odd assortment of
languages very often. The ambiguity of it meaning substring or
substitute and then having to look up in the docs exactly what it
means (if only for a beginner) is what I dislike. string.slice()
Makes more sense as it it's not a shorthand for what it's doing
string.sub(string|stitute) Eventually you do get used to knowing
exactly what they mean, but I'm sure some might argue that being as
clear as possible with function naming would be ideal over never
renaming them for backwards compatibility. I like the idea of most
(if not all) string functions using pattern matching where applicable.
A string.slice() with numerical arguments, a string.replace() with a
pattern, a string.match() with a pattern, a string.itermatch() to
denote the iterator... Of course, I have no power and this is merely
just a suggestion.. but if 5.2 is so near (or the next release), it
would be a fun time to consider stupid-simple/self-explanatory
function names... And you could always alias the old to the new
names..
Plain and simple, I think Lua is gaining a lot of ground and I am so
proud to be a part of it's growing userbase, but I'm willing to bet
these names will always cause hiccups for newbies and the forgetful
Lua regular. :>
PS: string.substr() doesn't seem to match convention where the
function names tend to either be the full word or have some one-letter
prefix (like string.gmatch()) So I guess a string.itermatch()
wouldn't work either, but string.imatch() would...
On Mon, Jan 18, 2010 at 6:34 PM, David Manura <dm.lua@math2.org> wrote:
> On Mon, Jan 18, 2010 at 9:28 PM, Ted Unangst wrote:
>> On Mon, Jan 18, 2010 at 8:54 PM, David Manura wrote:
>>> call it string.subst. I think most programmers would immediately
>>> guess what string.subst is, except maybe the part where it takes a
>>> pattern and function rather than plain strings.
>>
>> subst is short for substring right? :)
>
> Oh, true :) Usually, when languages want to abbreviate substring near
> the 't' they do so after the 'r': substr [1]
>
> Looking again, it would be more common just to name it "replace" [2].
>
> [1] http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28string_functions%29#substring
> [2] http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28string_functions%29#replace
>