String starts? and ends? methods

[George]

This comes up every now and again, and lots of frameworks implement their own versions. I'm thinking
of submitting an RCR for something functionally equivalent to the following to be incorporated into
the base library:

class String
def starts?(aString)
index(aString) == 0
end

def ends?(aString)
rindex(aString) == length - aString.length
end
end

Of course, the real implementation would have much better performance. The advantage of including
something like this is that these common functions can be made both high-performance and readable.

Comments?

 

[ts]

G> class String
G> def starts?(aString)
G> def ends?(aString)

1.9 has String#startwith?, String#endwith?


Guy Decoux

 

[George]

G> class String
G> def starts?(aString)
G> def ends?(aString)

1.9 has String#startwith?, String#endwith?

Where is this documented? I can't find it anywhere.

 

[dblack]

Hi --

G> class String
G> def starts?(aString)
G> def ends?(aString)

1.9 has String#startwith?, String#endwith?

No underscores between words?


David

--
David A. Black | (e-mail address removed)
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

 

[ts]

d> No underscores between words?

moulon% grep ith\? string.c
* str.startwith?([prefix]+) => true or false
* str.endwith?([suffix]+) => true or false
rb_define_method(rb_cString, "startwith?", rb_str_startwith, -1);
rb_define_method(rb_cString, "endwith?", rb_str_endwith, -1);
moulon%


Guy Decoux

 

[dblack]

Hi --

d> No underscores between words?

moulon% grep ith\? string.c
* str.startwith?([prefix]+) => true or false
* str.endwith?([suffix]+) => true or false
rb_define_method(rb_cString, "startwith?", rb_str_startwith, -1);
rb_define_method(rb_cString, "endwith?", rb_str_endwith, -1);
moulon%

It's not that I didn't believe you It just seems a bit unusual,
in terms of the general Ruby practice.


David

--
David A. Black | (e-mail address removed)
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

 

[Yukihiro Matsumoto]

Hi,

In message "Re: String starts? and ends? methods"
on Wed, 27 Sep 2006 20:53:54 +0900, (e-mail address removed) writes:

|It's not that I didn't believe you It just seems a bit unusual,
|in terms of the general Ruby practice.

Makes sense. It was just honoring the origin (this case Python).
Since they are young (I just added it last week), it is fairly easy to
change the names. Any opinion?

matz.

 

[Rimantas Liubertas]

Makes sense. It was just honoring the origin (this case Python).

Since they are young (I just added it last week), it is fairly easy to
change the names. Any opinion?

matz.

+1 for changing to start_with? end_with?

Consistency in naming is a big plus for ruby (and minus for PHP).


Regards,
Rimantas

 

[Robin Stocker]

Makes sense. It was just honoring the origin (this case Python).
Since they are young (I just added it last week), it is fairly easy to
change the names. Any opinion?

My vote is also for naming them start_with? and end_with? because of
consistency and better looks .

Robin

 

[dblack]

Hi --

Hi,

In message "Re: String starts? and ends? methods"
on Wed, 27 Sep 2006 20:53:54 +0900, (e-mail address removed) writes:

|It's not that I didn't believe you It just seems a bit unusual,
|in terms of the general Ruby practice.

Makes sense. It was just honoring the origin (this case Python).
Since they are young (I just added it last week), it is fairly easy to
change the names. Any opinion?

Yes: add the underscores. Otherwise we'll have those exceptions "for
historical reasons" -- in this case the history of Python!


David

--
David A. Black | (e-mail address removed)
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

 

[Yukihiro Matsumoto]

Hi,

In message "Re: String starts? and ends? methods"
on Wed, 27 Sep 2006 21:29:09 +0900, (e-mail address removed) writes:

|> Makes sense. It was just honoring the origin (this case Python).
|> Since they are young (I just added it last week), it is fairly easy to
|> change the names. Any opinion?
|
|Yes: add the underscores. Otherwise we'll have those exceptions "for
|historical reasons" -- in this case the history of Python!

OK, done.

matz.

 

[James Edward Gray II]

+1 for changing to start_with? end_with?

I agree completely.

James Edward Gray II

 

[Vincent Fourmond]

+1 for changing to start_with? end_with?

+ 1 for me as well

Vince

 

[Devin Mullins]

Makes sense. It was just honoring the origin (this case Python).
Since they are young (I just added it last week), it is fairly easy to
change the names. Any opinion?

My English-fu has me prefer starts_with? to start_with?, but general
Ruby convention seems to be not to conjugate the verbs, so I'll just
vote what everybody else is voting.

 

[Vincent Fourmond]

to be honest, i don't really think this is that useful.
what wrong with

string=~/^start/
string=~/end$/

this seems to be self-explanatory enough.

For the Regexp-friendly users... In my opinion, a part of Ruby's
coolness is that you have quite a lot of ways to say similar things,
which leaves you to chose the most readable for the code at hand (and
for your own eyes).

I don't expect having another method for String will cause a huge
performance drop ;-)... And I definitely think some code will look
easier to read with that.

Cheers !

Vince

 

[dblack]

Hi --

My English-fu has me prefer starts_with? to start_with?, but general Ruby
convention seems to be not to conjugate the verbs, so I'll just vote what
everybody else is voting.

It's a little inconsistent:

obj.respond_to? # second person
obj.is_a? # third person

But I think second person is the most common. Or maybe are_a? just
sounded too weird


David

--
David A. Black | (e-mail address removed)
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

 

[Logan Capaldo]

to be honest, i don't really think this is that useful.
what wrong with

string=~/^start/
string=~/end$/

That's almost right.
You want /\Astart/ and /end\z/

 

[Yukihiro Matsumoto]

Hi,

In message "Re: String starts? and ends? methods"
on Wed, 27 Sep 2006 22:40:29 +0900, (e-mail address removed) writes:

|It's a little inconsistent:
|
| obj.respond_to? # second person
| obj.is_a? # third person
|
|But I think second person is the most common. Or maybe are_a? just
|sounded too weird

Right. "is-a" is a too common phrase among object-oriented
programming. I wasn't brave enough to rename it "be_a" or something
like it.

matz.

 

[Jonas Hartmann]

Hi,

In message "Re: String starts? and ends? methods"
on Wed, 27 Sep 2006 22:40:29 +0900, (e-mail address removed) writes:

|It's a little inconsistent:
|
| obj.respond_to? # second person
| obj.is_a? # third person
|
|But I think second person is the most common. Or maybe are_a? just
|sounded too weird

Right. "is-a" is a too common phrase among object-oriented
programming. I wasn't brave enough to rename it "be_a" or something
like it.

matz.

(a newbie speaking)

but what about puralization?

we gonna have "string".respond_to?() but "string".starts_with?()

further: could there be need for starts_with!() and ends_with!() ? or
is it bollox?

 

[James Edward Gray II]

further: could there be need for starts_with!() and ends_with!() ?
or is it bollox?

What functionality are you envisioning these methods would have?

James Edward Gray II