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
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
···
On Tue, 29 Nov 2005, Warren Brown wrote:
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?.
#
# 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
--
ara [dot] t [dot] howard [at] noaa [dot] gov
all happiness comes from the desire for others to be happy. all misery
comes from the desire for oneself to be happy.
-- bodhicaryavatara
===============================================================================
Hi --
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?.
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
···
On Tue, 29 Nov 2005, ara.t.howard@noaa.gov wrote:
On Tue, 29 Nov 2005, Warren Brown wrote:
--
David A. Black
dblack@wobblini.net
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
···
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