# Redefining hat operator for Proc

**URL:** <https://www.ruby-forum.com/t/redefining-hat-operator-for-proc/176114>\
**Category:** Ruby\
**Created:** [September 24, 2009, 10:50pm UTC](https://www.ruby-forum.com/t/redefining-hat-operator-for-proc/176114 "2009-09-24T22:50:59Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![bparanj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/e9a140/32.png) [@bparanj](https://www.ruby-forum.com/u/bparanj)\
**Post date:** [September 24, 2009, 10:50pm UTC](https://www.ruby-forum.com/t/redefining-hat-operator-for-proc/176114/1 "2009-09-24T22:50:59Z")

</div>

Hello,

I am developing a gem where I need to redefine the \<=\> operator for  
Proc. This operator shows up in the methods list when I print the  
output of methods call but I don’t see it in the list of private or  
protected methods.

I know in Ruby 1.9 === operator has been redefined, but I am not able  
to confirm that \<=\> is currently implemented in Ruby 1.9. I don’t want  
to over-ride the hat operator if it is already implemented for Proc.  
Could someone please give me some pointers?

TIA.  
Bala

---

<div class="post-metadata">

**Author:** ![bparanj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/e9a140/32.png) [@bparanj](https://www.ruby-forum.com/u/bparanj)\
**Post date:** [September 24, 2009, 11:03pm UTC](https://www.ruby-forum.com/t/redefining-hat-operator-for-proc/176114/2 "2009-09-24T23:03:17Z")

</div>

bparanj:

> I am developing a gem where I need to redefine the \<=\> operator for  
> Proc. This operator shows up in the methods list when I print the  
> output of methods call but I don’t see it in the list of private or  
> protected methods.

> > puts RUBY\_DESCRIPTION  
> > ruby 1.9.1p243 (2009-07-16 revision 24175) [x86\_64-linux]  
> > =\> nil
> 
> > Proc.instance\_methods.include? :\<=\>  
> > =\> false

Where do you see it?

Also,

> > a = Proc.new {}  
> > =\> #Proc:0x000000028d37e0@:6(irb)
> 
> > b = Proc.new {}  
> > =\> #Proc:0x000000028c8a30@:7(irb)
> 
> > a \<=\> b  
> > NoMethodError: undefined method `<=>' for #<Proc:0x000000028d37e0@(irb):6> from (irb):8 from /home/shot/.rvm/ruby-1.9.1-p243/bin/irb:12:in`’

— Shot

---

<div class="post-metadata">

**Author:** ![bparanj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/e9a140/32.png) [@bparanj](https://www.ruby-forum.com/u/bparanj)\
**Post date:** [September 24, 2009, 11:31pm UTC](https://www.ruby-forum.com/t/redefining-hat-operator-for-proc/176114/3 "2009-09-24T23:31:24Z")

</div>

On 09/24/2009 10:47 PM, bparanj wrote:

> Could someone please give me some pointers?  
> If you do Proc.instance\_method(:\<=\>), what do you get? If nil, then  
> it’s not overridden.

Cheers

robert

---

<div class="post-metadata">

**Author:** ![bparanj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/e9a140/32.png) [@bparanj](https://www.ruby-forum.com/u/bparanj)\
**Post date:** [September 25, 2009, 12:25am UTC](https://www.ruby-forum.com/t/redefining-hat-operator-for-proc/176114/4 "2009-09-25T00:25:52Z")

</div>

> If you do Proc.instance\_method(:\<=\>), what do you get? If nil, then  
> it’s not overridden.
> 
> Cheers
> 
> ```
> robert
> 
> ```

irb(main):005:0\> p = Proc.instance\_method(:\<=\>)  
NameError: undefined method `<=>' for class`Proc’  
from (irb):5:in `instance_method' from (irb):5 from /usr/local/bin/irb:12:in`’

Looks like it is safe to redefine it. Thanks.

---

<div class="post-metadata">

**Author:** ![bparanj](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/e9a140/32.png) [@bparanj](https://www.ruby-forum.com/u/bparanj)\
**Post date:** [September 25, 2009, 1:50am UTC](https://www.ruby-forum.com/t/redefining-hat-operator-for-proc/176114/5 "2009-09-25T01:50:11Z")

</div>

Hi –

On Fri, 25 Sep 2009, bparanj wrote:

> NameError: undefined method `<=>' for class`Proc’  
> from (irb):5:in `instance_method' from (irb):5 from /usr/local/bin/irb:12:in`’
> 
> Looks like it is safe to redefine it. Thanks.

You just have to hope that no one else comes to the same conclusion  
🙂

David