Forum: Ruby Re: string range membership

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Dbda3094a2f929a0658bedd4e0787a56?d=identicon&s=25 warrenbrown (Guest)
on 2005-11-28 18:51
(Received via mailing list)
Matz,

>> What about Range#include??  Would it still be an
>> alias for Range#member?, or would it retain the
>> current interval check?
>
> No decided yet.  Feel free to say your opinion.

    Well, I tend to agree with your previous decision on this.  Having
Enumerable#include? be an alias for Enumerable#member? (or vice-versa),
but having Range#include? behave differently from Range#member? would be
confusing.  I think it would be better to leave these two methods as
aliases and add a new method to Range for the interval check.  My
leading candidate for this method is now David A. Black's suggestion of
#encompass?.  This is a great name and I really like his idea of
extending it to accept Ranges as parameters so that
(1..10).encompass?(2..9) == true.  Other synonyms could also work:
#enclose?, #surround?, and even #contain?.

    - Warren Brown
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 ara.t.howard (Guest)
on 2005-11-28 19:24
(Received via mailing list)
On Tue, 29 Nov 2005, Warren Brown wrote:

> but having Range#include? behave differently from Range#member? would be
> confusing.  I think it would be better to leave these two methods as
> aliases and add a new method to Range for the interval check.  My
> leading candidate for this method is now David A. Black's suggestion of
> #encompass?.  This is a great name and I really like his idea of
> extending it to accept Ranges as parameters so that
> (1..10).encompass?(2..9) == true.  Other synonyms could also work:
> #enclose?, #surround?, and even #contain?.

reading this just gave me a new idea:  first of all, i think this method
should be a verb so that it implies a loop and test, rather than a
simply
test.  this is important because the method is, potentally, extremely
expensive.  shortening you suggesting then, how about

   (0 ... 42).pass? 42  #=> false
   (0 .. 42).pass? 42  #=> false

for example:

   harp:~ > cat a.rb
   module Enumerable
     #
     # Enumerable#pass? member
     #   true if the each method will yield member
     #
       def pass? member
         each{|element| return(element ? element : true) if member ===
element}
         return nil
       end
   end

   p (0 ... 42).pass?(42)
   p (0 .. 42).pass?(42)
   p [0,1,2,nil].pass?(nil)

   open(".bashrc") do |f|
     if ((line = f.pass? %r/screen/))
       puts line
     end
   end


   harp:~ > ruby a.rb
   nil
   42
   true
   alias ss='screen -S '

thoughts?

-a
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 vjoel (Guest)
on 2005-11-28 20:12
(Received via mailing list)
ara.t.howard@noaa.gov wrote:
>   (0 ... 42).pass? 42  #=> false
>   (0 .. 42).pass? 42  #=> false

(0..42).pass? 40.5

true or false?
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 dblack (Guest)
on 2005-11-28 20:21
(Received via mailing list)
Hi --

On Tue, 29 Nov 2005, ara.t.howard@noaa.gov wrote:

>>    Well, I tend to agree with your previous decision on this.  Having
> reading this just gave me a new idea:  first of all, i think this method
> should be a verb so that it implies a loop and test, rather than a simply
> test.  this is important because the method is, potentally, extremely
> expensive.

"encompass" is a verb :-)


> shortening you suggesting then, how about
>
>  (0 ... 42).pass? 42  #=> false
>  (0 .. 42).pass? 42  #=> false

I don't get how "pass" relates to ranges, or enumerables generally.
Do you mean because it will be "passed" to the block?  That seems like
focusing on the mechanics rather than the semantics of the object.
(But maybe I'm misunderstanding.)


David
2cf6d8e639314abd751f83a72e9a2ac5?d=identicon&s=25 martindemello (Guest)
on 2005-11-29 14:48
(Received via mailing list)
ara.t.howard@noaa.gov wrote:
>
> reading this just gave me a new idea:  first of all, i think this method
> should be a verb so that it implies a loop and test, rather than a simply
> test.  this is important because the method is, potentally, extremely
> expensive.  shortening you suggesting then, how about

I suggested #generates? elsewhere in the thread, for the same reason - I
think it important that the method sounds expensive. Are there any
methods currently in the core/stdlib that sound innocuous but have a
performance hit under the covers? (#last perhaps?).

martin
This topic is locked and can not be replied to.