Symbols are your friends

[Daniel Schierbeck]

Yes, it's time for another Symbol trick!

class Symbol
def ===(obj)
obj.respond_to? "to_#{self}"
end
end

case "foo"
when :int then "integer"
when :str then "string"
when :ary then "array"
end #=> "string"

Genius. Sheer genius.


Daniel

 

[Caleb Clausen]

Yes, it's time for another Symbol trick!

class Symbol
def ===(obj)
obj.respond_to? "to_#{self}"
end
end

This idea has been discussed on this list before; I can't find the
thread at the moment.
This seems like a really clever idea, and is fine for just playing
around... but it's not advisable for general use. You're changing the
semantics of Symbol#===, which will break things like this:

case method_name
when :reverse
#....
when :each
#...
else #.....
end

The following is a simplified extract of what I use in Reg for a
similar feature. It's safer, as long as nothing else decides to do
something with Symbol#-@.

class Symbol
def -@; Reg::Knows.new(self) end
end

module Reg
class Knows
def initialize(sym)
@sym=sym
end
def ===(other)
other.respond_to? @sym
end
end
end


(You're prepending "to_" to your method names before checking; I don't
know why. This way seems more general....)

 

[Daniel Schierbeck]

This idea has been discussed on this list before; I can't find the
thread at the moment.
This seems like a really clever idea, and is fine for just playing
around... but it's not advisable for general use. You're changing the
semantics of Symbol#===, which will break things like this:

case method_name
when :reverse
#....
when :each
#...
else #.....
end

Yes, that's true -- I only ever intended it to be a trick.

(You're prepending "to_" to your method names before checking; I don't
know why. This way seems more general....)

I was using it to demonstrate how you could duck type check with a case
statement, so focusing on the "type" made sense. I see this all the time:

case obj
when Integer then foo
when String then bar
end

and it strikes me as not being very duckish (quacky?) Using if
statements can be annoying:

if obj.respond_to? :to_str
foo
elsif obj.respond_to? :to_int
bar
end

Maybe this would work?

class Symbol
def ===(obj)
return true if self == obj
obj.respond_to? "to_#{self}"
end
end

though something like this may cause trouble:

obj = :int
case obj
when :int then "integer"
when :str then "string"
end


Cheers,
Daniel

 

[Caleb Clausen]

I was using it to demonstrate how you could duck type check with a case
statement, so focusing on the "type" made sense. I see this all the time:

case obj
when Integer then foo
when String then bar
end

and it strikes me as not being very duckish (quacky?) Using if
statements can be annoying:

if obj.respond_to? :to_str
foo
elsif obj.respond_to? :to_int
bar
end

I see where you're coming from, but I guess I just don't see that
#to_* methods as being that special. Why wouldn't you want to do this
kind of dispatch for other methods too?

Using the code I posted previously, the above conditionals could be written as:

case obj
when -:to_str
foo
when -:to_int
bar
end

I like that one best.

Fooling with the existing Symbol#=== in any way is very likely to
break some existing libs which assumes the current definition always
obtains... my way lets you use (almost-)symbols in the way you want to
use them. It is incompatible with libs that also define Symbol#-@ in a
different way, but those are presumably much rarer, perhaps
nonexistant. (Nobody's as crazy as I am.) If you really want this
feature in a general way, (and I do, for Reg) this seems to be the
best compromise.

 

[Daniel Schierbeck]

I see where you're coming from, but I guess I just don't see that
#to_* methods as being that special. Why wouldn't you want to do this
kind of dispatch for other methods too?

Because I only think the #to_x methods are directly related to types.
They even have more nuances than class-based types; there's a difference
between defining #to_s and defining #to_str, for example.

Using the code I posted previously, the above conditionals could be
written as:

case obj
when -:to_str
foo
when -:to_int
bar
end

I like that one best.

Fooling with the existing Symbol#=== in any way is very likely to
break some existing libs which assumes the current definition always
obtains... my way lets you use (almost-)symbols in the way you want to
use them. It is incompatible with libs that also define Symbol#-@ in a
different way, but those are presumably much rarer, perhaps
nonexistant. (Nobody's as crazy as I am.) If you really want this
feature in a general way, (and I do, for Reg) this seems to be the
best compromise.

Yes, I've adopted your solution; it is indeed the best way to get around
the problem.

This isn't something I believe should go into core or anything, I just
think it's a great showcase of Ruby's flexibility.


Cheers,
Daniel

 

[Aleks Kissinger]

Because I only think the #to_x methods are directly related to types.

They even have more nuances than class-based types; there's a difference
between defining #to_s and defining #to_str, for example.

In the spirit of making sure I understand, and perhaps explaining this
to anyone else that may be confused, the difference in these two kinds
of methods:

If an object _can_ be represented as an integer in some cases (e.g. a
string, which could be set to something like "12"), it implements
to_i.

If an object _is_ a natural representation of an integer, (like roman
numerals, as the example the Pickaxe gives), it implements to_int.

So this makes sense, though nothing about the naming convention of
these methods makes this particularly clear. However, this brings up
the question: If something acts exactly like an integer method-wise,
whats the benefit of explicitly calling to_int? This seems like a non
duck-typey thing to do.


Aleks

 

[ara.t.howard]

So this makes sense, though nothing about the naming convention of these
methods makes this particularly clear. However, this brings up the
question: If something acts exactly like an integer method-wise, whats the
benefit of explicitly calling to_int? This seems like a non duck-typey
thing to do.

- it might be faster to actually have an int

- you can fail early by filtering on one 'category' of behaviours guaranteed
by having an object respond_to? 'to_int', this is not unlike type or
interface checking

-a

 

[Aleks Kissinger]

That makes sense. Thanks.

- it might be faster to actually have an int

- you can fail early by filtering on one 'category' of behaviours guaranteed
by having an object respond_to? 'to_int', this is not unlike type or
interface checking

-a

 

[Daniel Schierbeck]

If an object _can_ be represented as an integer in some cases (e.g. a
string, which could be set to something like "12"), it implements
to_i.

If an object _is_ a natural representation of an integer, (like roman
numerals, as the example the Pickaxe gives), it implements to_int.

That very nicely sums it up!

So this makes sense, though nothing about the naming convention of
these methods makes this particularly clear. However, this brings up
the question: If something acts exactly like an integer method-wise,
whats the benefit of explicitly calling to_int? This seems like a non
duck-typey thing to do.

In the example with the roman numerals, you might not want to implement
all the behavior of Numeric or Fixnum -- it would make your class
unnecessarily complex. Rather just have a #to_int method that returned a
normal integer, be that a Fixnum or another object responded to the same
methods. In many cases, you have to return a Fixnum, or some methods
will complain.

This approach means that you can give your roman numeral objects
directly as arguments to methods. If they call #to_int on the object
before dealing with it, it'll behave just as if it's a Fixnum.

# doesn't really have to be an integer,
# but what the hell...
def double(num)
num.to_int * 2
end

double(roman_num)


Cheers,
Daniel