Symbol#===

7rans · 25 June 2011 05:57

As:

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

Then:

    case foo
    when :some_method
      foo.some_method
    end

Insanity?

David_Masover · 25 June 2011 06:25

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.

···

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

As:

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

Then:

    case foo
    when :some_method
      foo.some_method
    end

Insanity?

Josh_Cheek · 25 June 2011 06:27

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).

···

On Sat, Jun 25, 2011 at 12:57 AM, Intransition <transfire@gmail.com> wrote:

As:

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

Then:

   case foo
   when :some_method
     foo.some_method
   end

Insanity?

Forum · 25 June 2011 17:00

As:

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

Then:

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

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

···

On Sat, Jun 25, 2011 at 7:57 AM, Intransition <transfire@gmail.com> wrote:

--
I'm not against types, but I don't know of any type systems that
aren't a complete pain, so I still like dynamic typing.
--
Alain Kay

7rans · 25 June 2011 19:15

> As:

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

> Then:

> 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

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?

···

On Jun 25, 1:00 pm, Robert Dober <robert.do...@gmail.com> wrote:

On Sat, Jun 25, 2011 at 7:57 AM, Intransition <transf...@gmail.com> wrote:

Robert_K1 · 28 June 2011 12:57

> As:

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

> Then:

> case foo
> when :some_method
> foo.some_method
> end

> Insanity?

Maybe, maybe not... The two of me can't really agree...

No, but too invasive...

case my_token
when :integer
when :identifier
when....

thanx for breaking that

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!

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

···

On Sat, Jun 25, 2011 at 9:15 PM, Intransition <transfire@gmail.com> wrote:

On Jun 25, 1:00 pm, Robert Dober <robert.do...@gmail.com> wrote:

On Sat, Jun 25, 2011 at 7:57 AM, Intransition <transf...@gmail.com> wrote:

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Robert_K1 · 28 June 2011 13:01

P.S.: I believe it must be

class Prince
...
end

again. The name was reverted back to the original.

robert

···

On Tue, Jun 28, 2011 at 2:57 PM, Robert Klemme <shortcutter@googlemail.com> wrote:

On Sat, Jun 25, 2011 at 9:15 PM, Intransition <transfire@gmail.com> wrote:

On Jun 25, 1:00 pm, Robert Dober <robert.do...@gmail.com> wrote:

On Sat, Jun 25, 2011 at 7:57 AM, Intransition <transf...@gmail.com> wrote:
> As:

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

> Then:

> case foo
> when :some_method
> foo.some_method
> end

> Insanity?

Maybe, maybe not... The two of me can't really agree...

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Forum · 28 June 2011 15:04

<snip>
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

···

On Tue, Jun 28, 2011 at 2:57 PM, Robert Klemme <shortcutter@googlemail.com> wrote:

On Sat, Jun 25, 2011 at 9:15 PM, Intransition <transfire@gmail.com> wrote:

--
I'm not against types, but I don't know of any type systems that
aren't a complete pain, so I still like dynamic typing.
--
Alain Kay

Josh_Cheek · 28 June 2011 16:44

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]

···

On Tue, Jun 28, 2011 at 10:04 AM, Robert Dober <robert.dober@gmail.com>wrote:

On Tue, Jun 28, 2011 at 2:57 PM, Robert Klemme > <shortcutter@googlemail.com> wrote:
> On Sat, Jun 25, 2011 at 9:15 PM, Intransition <transfire@gmail.com> > wrote:
<snip>
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....

Forum · 29 June 2011 08:17

<snip>
Duly noted I do not change my POV but I will not evangelize of course.

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]

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

···

On Tue, Jun 28, 2011 at 6:44 PM, Josh Cheek <josh.cheek@gmail.com> wrote:

On Tue, Jun 28, 2011 at 10:04 AM, Robert Dober <robert.dober@gmail.com>wrote:

--
I'm not against types, but I don't know of any type systems that
aren't a complete pain, so I still like dynamic typing.
--
Alain Kay

Forum · 29 June 2011 08:58

<snip>

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.

···

On Tue, Jun 28, 2011 at 6:44 PM, Josh Cheek <josh.cheek@gmail.com> wrote:

Topic		Replies	Views
Case Expressions and Classes ruby-talk	6	152	19 August 2005
Symbols are your friends ruby-talk	8	68	28 July 2006
=== confusion ruby-talk	1	109	9 February 2004
When should x.eql?(y) != (x == y)? ruby-talk	0	112	19 October 2005
Surprising: class A; end; A === A ==> false ruby-talk	9	114	25 February 2005

Symbol#===

Related topics