Symbol#===

Ruby
1

As:

class Symbol
  def ===(object)
    object.respond_to?(self)
  end
end

Then:

case foo
when :some_method
  foo.some_method
end

Insanity?

2

On Saturday, June 25, 2011 12:57:51 AM Intransition wrote:

case foo
when :some_method
  foo.some_method
end

Insanity?

Maybe. It makes things somewhat ambiguous if I wanted to only compare a
Symbol
with that case statement.

…I think? I tend to use if statements more often anyway.

3

On Sat, Jun 25, 2011 at 12:57 AM, Intransition [email protected]
wrote:

case foo
when :some_method
foo.some_method
end

Insanity?

I suppose it is indicative of how case statements were thought about
during
their conception (ie not replacements for if statements, but rather for
making apis more robust).

4

On Jun 25, 1:00pm, Robert D. [email protected] wrote:

when :integer
when :identifier
when…

thanx for breaking that :wink:

lol. let me “fix” it for you

class Symbol
  def ===(object)
    return super(object) if Symbol === object
    object.respond_to?(self)
  end
end

Of course, now no repsond_to? case checking for Symbols!

Furthermore I already feel that Symbol has one of the worst kludges
ever conceived cast onto itself, which is #to_proc. On the same
account I feel #=== should not be concerned with receiver’s methods.

#to_proc that bad?

5

On Sat, Jun 25, 2011 at 7:57 AM, Intransition [email protected]
wrote:

case foo
when :some_method
foo.some_method
end

Insanity?
No, but too invasive…

case my_token
when :integer
when :identifier
when…

thanx for breaking that :wink:

Furthermore I already feel that Symbol has one of the worst kludges
ever conceived cast onto itself, which is #to_proc. On the same
account I feel #=== should not be concerned with receiver’s methods.

Cheers
Robert

6

On Sat, Jun 25, 2011 at 9:15 PM, Intransition [email protected]
wrote:

end

Then:

case foo
when :some_method
foo.some_method
end

Insanity?

Maybe, maybe not… The two of me can’t really agree… :slight_smile:

class Symbol
def ===(object)
return super(object) if Symbol === object
object.respond_to?(self)
end
end

Of course, now no repsond_to? case checking for Symbols!

I’d rather keep this simpler:

class Symbol
def ===(o)
equal? o or o.respond_to? self
end
end

irb(main):012:0> :s === :s
=> true
irb(main):013:0> :length === “foo”
=> true
irb(main):014:0> :nono === “bar”
=> false

Furthermore I already feel that Symbol has one of the worst kludges
ever conceived cast onto itself, which is #to_proc. On the same
account I feel #=== should not be concerned with receiver’s methods.

#to_proc that bad?

No, I like it.

Kind regards

robert

7

Ok and what can I do with this?

class Symbol
def ===(object)
object.respond_to?(self)
end
end

Then:

case foo
when :some_method
foo.some_method
end

I mean we can do a lot in ruby but I am not sure about how useful this
here is?

8

On Tue, Jun 28, 2011 at 2:57 PM, Robert K.
[email protected] wrote:

On Sat, Jun 25, 2011 at 9:15 PM, Intransition [email protected] wrote:

Thx for fixing it;)
still not the biggest fan of it though

No, I like it.
Really, I mean do you like to use it, as do I, or do you like it
conceptionally? I would much prefer map(:to_s) to map(&:to_s) because
now it is each’s responsibility of what to do with a symbol, and map
could even intercept. It also gives it much more possibilities as e.g.
map(:+,42). And other methods than #each could do completely other
things, especially not allowing symbols to be passed in, imagine e.g.

config(&:hello!)

Loading the responsibility of to_proc to Symbol I dunno, but anyway it
will be here for ever now…

Cheers
Robert

9

On Tue, Jun 28, 2011 at 10:04 AM, Robert D.
[email protected]wrote:

conceptionally? I would much prefer map(:to_s) to map(&:to_s) because

I think it is best the way it is. They want a function, you’re providing
one. That is pretty straight forward and conceptually elegant (even if
it
can get ugly to look at).

This makes it consistent everywhere. If you instead pass that
possibility to
#map, you will end up with lots of edge cases where some methods don’t
implement it the same and some don’t implement it at all and so forth. I
consider these kinds of inconsistencies to be often times harmful, and
nearly always distasteful.

For example: unix command line programs interpreting their flags however
they like thus leading to highly inconsistent interfaces. Every time I
use
find, for example, I check $ cheat find.

I think your example of map(:+, 42) would be better achieved with more
functional support. Something along these lines:
def f(meth, *args)
Proc.new do |obj|
obj.send meth, *args
end
end
nums = [10, 20, 30]
nums.map(&(f :+, 5)) # => [15, 25, 35]
nums.map(&(f :-, 5)) # => [5, 15, 25]

10

On Tue, Jun 28, 2011 at 6:44 PM, Josh C. [email protected]
wrote:

On Tue, Jun 28, 2011 at 10:04 AM, Robert D. [email protected]wrote:

Duly noted :wink: I do not change my POV but I will not evangelize of
course.

Using, what I believe is, a functor is indeed a nice idea. N.B. I have
nothing against #to_proc in general.
Cheers
R.

11

On Tue, Jun 28, 2011 at 2:57 PM, Robert K.
[email protected] wrote:

end

Maybe, maybe not… The two of me can’t really agree… :slight_smile:

P.S.: I believe it must be

class Prince
…
end

again. The name was reverted back to the original. :wink:

robert

12

On Tue, Jun 28, 2011 at 6:44 PM, Josh C. [email protected]
wrote:

For example: unix command line programs interpreting their flags however
they like thus leading to highly inconsistent interfaces. Every time I use
find, for example, I check $ cheat find.
Ohh that makes me think of this, I am working with rails2.3.9 in the
office and with rails3.1 @ home.
It is indeed a pain in one of the rear facing lower body parts, but in
this case I believe everyone
agrees, that is the price to pay though.
R.