G
gwtmp01
I started this post after wondering why
Set doesn't alias :=== to :include?
That led me to look at ===, include?, and =~ for a variety
of classes...
The following table shows the results of executing
pattern.send(method, arg)
Pattern Arg === include? =~
/foo/ "foo" yes fails yes
0..10 5 yes yes Object#=~
["foo"] "foo" Array#== yes Object#=~
Set.new ["foo"] "foo" Set#== yes Object#=~
{"foo", nil} "foo" Hash#== yes Object#=~
String "foo" yes fails Object#=~
yes means that a class specific method definition exists.
Object#=~ always returns false.
Regexp#=== is the same as Regexp#=~
Range#=== is the same as Range#include?
Could ===, include?, and =~ all be unified?
Does anyone have an example where the semantics of these
three methods should be different (other than for
backward compatibility)?
For the "collection" classes (Array, Set, Hash), the ===
method defaults to using the class specific == method.
Does it make sense for === to be semantically equivalent to ==
for "collection" classes? It seems quite reasonable for "value"
classes where case/when/end can be used to look for particular
values but for a collection class a "pattern" match behavior
would seem more useful when the argument is not also a collection.
Collection === element # membership/inclusion test
Collection === Collection # == test
Are there any examples where =~ and === are defined but aren't
aliases for each other?
Minimally, it would seem that Regexp#include? could be aliased
to Regexp#=~ and Class#include? could be aliased to Class#===
This would make collection.include?(element) a "pattern" test
for all the classes I looked at.
Set doesn't alias :=== to :include?
That led me to look at ===, include?, and =~ for a variety
of classes...
The following table shows the results of executing
pattern.send(method, arg)
Pattern Arg === include? =~
/foo/ "foo" yes fails yes
0..10 5 yes yes Object#=~
["foo"] "foo" Array#== yes Object#=~
Set.new ["foo"] "foo" Set#== yes Object#=~
{"foo", nil} "foo" Hash#== yes Object#=~
String "foo" yes fails Object#=~
yes means that a class specific method definition exists.
Object#=~ always returns false.
Regexp#=== is the same as Regexp#=~
Range#=== is the same as Range#include?
Could ===, include?, and =~ all be unified?
Does anyone have an example where the semantics of these
three methods should be different (other than for
backward compatibility)?
For the "collection" classes (Array, Set, Hash), the ===
method defaults to using the class specific == method.
Does it make sense for === to be semantically equivalent to ==
for "collection" classes? It seems quite reasonable for "value"
classes where case/when/end can be used to look for particular
values but for a collection class a "pattern" match behavior
would seem more useful when the argument is not also a collection.
Collection === element # membership/inclusion test
Collection === Collection # == test
Are there any examples where =~ and === are defined but aren't
aliases for each other?
Minimally, it would seem that Regexp#include? could be aliased
to Regexp#=~ and Class#include? could be aliased to Class#===
This would make collection.include?(element) a "pattern" test
for all the classes I looked at.
=3D=3D=3D,:include?)