"Austin Ziegler" <halostatue@gmail.com> schrieb im Newsbeitrag
news:9e7db911040822170976892f3b@mail.gmail.com...
Yet another alternative is to add an optional parameter in all cases.
String#gsub currently expects a regexp and a replace pattern OR a
regexp and a block. #gsub could be modified such that when it gets a
regexp, a "boolean", and a block, it yields something different. This
could be, for example:
Adding a flag to change method behavior is usually regarded bad OO practice.
The usual solution is to have two different methods - one for each behavior.
That increases modularity, simplifies the implementation and improves
performance.
I'd rather have String#gsub_md, String#gsub_md! and String#scan_md than the
flag although I have to admit that those method names are ugly.
[Note: I'm continuing the discussion here, because RCR276 seems to
have some data disappearing on a regular basis. David, if you're
generating rdiffs for the Wiki discussion, it might be nice if you
could send me a .tar.gz of the rdiff associated with RCR276 so that I
can see if my changes are making it in the first place.]
I agree that the presence of the flag may not be ideal, but note that #gsub already uses such conditional work -- and not having the flag
would actually cause unnecessary code duplication (per the C code
above). Right now, it accepts #gsub(patt, repl) or #gsub(patt, repl) {
repl-block }; this would extend the capability to include #gsub(patt,
repl-type) { repl-block }, the repl-type determining what is yielded.
Again: this is entirely about the yielded value. I believe that all
forms are correct for how they work when they don't use a block.
The idea of having #gsub with the flag (as opposed to the #gsubm [the
name I had chosen instead of #gsub_md) form which I rejected in
writing my response to Nobu) is that IMO we should encourage the use
of the new form with MatchData objects, not the other form. By using #gsubm, we discourage the use of the new form in favour of the old
form. The only way that I think that this would really work is to have #gsub yield MatchData and #gsubs yield Strings, if we take that
approach. --AustinZiegler
···
On Mon, 23 Aug 2004 16:20:55 +0900, Robert Klemme <bob.news@gmx.net> wrote:
"Austin Ziegler" <halostatue@gmail.com> schrieb im Newsbeitrag
news:9e7db911040822170976892f3b@mail.gmail.com...
> Yet another alternative is to add an optional parameter in all cases.
> String#gsub currently expects a regexp and a replace pattern OR a
> regexp and a block. #gsub could be modified such that when it gets a
> regexp, a "boolean", and a block, it yields something different. This
> could be, for example:
Adding a flag to change method behavior is usually regarded bad OO practice.
The usual solution is to have two different methods - one for each behavior.
That increases modularity, simplifies the implementation and improves
performance.
I'd rather have String#gsub_md, String#gsub_md! and String#scan_md than the
flag although I have to admit that those method names are ugly.
Wouldn't it be better to introduce a new method String#substitute.
I think #gsub and #sub are too short and their name doesn't really
says what they do. When I was new to ruby I recall that I had problems
distinguishing between #sub and #gsub.
I also want substitute to take a hash with options, like this:
:repeat, which says how many times that substitution should occur.
For instance :repeat=>1 is equal to #sub
For instance :repeat=>nil is equal to #gsub
It could also be named :repeat_once=>true
:literal, which tells #substitute that the content of
the replacement string should be interpreted as literal.. no extra-escaping
are then necessary.
For instance
string.substitute(/pa(tt)ern/, 'a\1b', :literal=>true)
will insert 'a\1b' as literal, without inserting capture 1.
Maybe there is other options.
when supplied a block, then it should yield matchdata
string.substitute(/pattern/) do |matchdata|
matchdata[2].reverse
end
"Austin Ziegler" <halostatue@gmail.com> schrieb im Newsbeitrag
news:9e7db91104082311481dae7133@mail.gmail.com...
The idea of having #gsub with the flag (as opposed to the #gsubm [the
name I had chosen instead of #gsub_md) form which I rejected in
writing my response to Nobu) is that IMO we should encourage the use
of the new form with MatchData objects, not the other form. By using #gsubm, we discourage the use of the new form in favour of the old
form. The only way that I think that this would really work is to have #gsub yield MatchData and #gsubs yield Strings, if we take that
approach. --AustinZiegler
Please bear in mind that the new form is not appropriate in all cases. For
some applications it comes very handy that those mehtods yield a String. So
although I like the new methods (that yield MatchData) and would really like
to see them one way or another in Ruby, I merely see them as complement to
the existing set of methods. For me there is no urge to encourage usage of
the new form and / or phase out the old methods. I'd rather have both of
them available with separate names so I can freely choose from them
whichever variant is best in a certain situation.
On Monday 23 August 2004 21:12, Simon Strandgaard wrote:
[snip talk about substitute]
> string.substitute(/pattern/, 'replacement', :option1=>1, :option2=>2)
if String#substitute is too long.. then maybe name it String#alter
> [snip talk about substitute]
> > string.substitute(/pattern/, 'replacement', :option1=>1, :option2=>2)
>
> if String#substitute is too long.. then maybe name it String#alter
String#replace
What would you replace the current String#replace with?
And alias :s :replace for unix diehards
No -- leave it comprehensible, for Ruby diehards
David
···
On Tue, 24 Aug 2004, Martin DeMello wrote:
Simon Strandgaard <neoneye@adslhome.dk> wrote:
> On Monday 23 August 2004 21:12, Simon Strandgaard wrote:
