From: Quinn Dunkan <quinn / envy.ugcs.caltech.edu>

> > From: Yukihiro Matsumoto <matz / netlab.co.jp>
> > > What's the benefit of foo.s(/pat/, "repl", "g") over foo.gsub(/pat/,
> > "repl")?
> >
> > In vi, sed, and perl, you don't thing of sub and gsub as being two
different
> > methods, but rather as a single method that is modulated by optional
> > parameters--including g, i, s, m, o, e, and x in perl (IIRC), which I
> > wouldn't want to see replaced by individual methods, since I (currently)
> > think it is much more natural to regard all of these things as
variations on
> > a common theme.
> >
> > Since I also use vi (actually gvim, a vastly improved GUI-based
extension of
> > vi) all the time and have used perl a lot in the past, "s" seems like
the
> > simplest and most natural name for what also seems to be most naturally
> > regarded as a single method. Actually, since awk always seemed awkward
to me
> > even before I discovered perl, maybe I should say that because I think
"s"
> > this is a more natural way to think of substitution, I happened to like
the
> > way that vi and perl do it.
>
> Well, the way ruby does things currently makes sense to me.  And ruby's
> Regexps already support parameters: /foo/i  But 'g' doesn't make sense as
a
> Regexp flag, it's a parameter to only the sub method.

Did you mean proposed parameter to the sub method? Why then would you not
regard the i, o, p, and x flags as potential sub method parameters as well?
However, from a more pattern-centric perspective, it might make more sense
to regard 'g' as another option/al flag (i.e. as another regexp option/al
parameter).

> I *would* argue against
> calling the method 's', even though I too have used vim since 1.0 on the
> amiga: sub is only two characters longer and so much more descriptive.
It's
> fine that editors use 's', but an editor is not a general-purpose
programming
> language (have you tried to read a screenful of complicated vi macros?).

You are comparing apples to orangutans, but yes. You would have to change a
lot more than one or two methods to make Ruby code look anything even
remotely similar.

> I like the fact that ruby is not vi, sed, and perl.

And hopefully, someday, is not awk in a similar sense either.

> So I have no problem with file://.sub vs file://.gsub  I also have no
problem with
> file://.sub('repl', g=1) or whatever.  But abbreviating to single
characters and
> inventing special calling semantics so you can write like a
special-purpose
> language I don't like so much.

No problem. I don't care about literally using 's' instead of 'sub', I was
just (unclearly--sorry) using "s" to designate the single method versus
multiple method perspective.

In fact, for example, except for $_ and $&, I generally prefer to use the
longer and more self-descriptive "use English" versions of Perl's special
variables, although some of them I think are a little too long. I wish Ruby
had originally designed in something of a happy medium for these things.

Conrad