Ruby's inconsistency or an IRB issue?

ruby-talk
1

Hi,

I've discovered some strange behaviour in Interactive Ruby shell (IRB) I
cann't explain myself. It manifests only with Wirble enhacement with
colorization enabled.

Class.methods.uniq.sort

=> [:!, :!, :!, :, :, :=>, :, :, :, :, :, :__id__, :__send__, :allocate,
:ancestors, :autoload, :autoload?, :class, :class_eval, :class_exec,
:class_variable_defined?, :class_variable_get, :class_variable_set,
:class_variables, :clone, :const_defined?, :const_get, :const_missing,
:const_set, :constants, :define_singleton_method, :display, :dup,
:enum_for, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :include?,
:included_modules, :initialize_clone, :initialize_dup, :inspect,
:instance_eval, :instance_exec, :instance_method, :instance_methods,
:instance_of?, :instance_variable_defined?, :instance_variable_get,
:instance_variable_set, :instance_variables, :is_a?, :kind_of?, :method,
:method_defined?, :methods, :module_eval, :module_exec, :name, :nesting,
:new, :nil?, :object_id, :po, :poc, :pretty_inspect, :pretty_print,
:pretty_print_cycle, :pretty_print_inspect,
:pretty_print_instance_variables, :private_class_method,
:private_instance_methods, :private_method_defined?, :private_methods,
:protected_instance_methods, :protected_method_defined?,
:protected_methods, :public_class_method, :public_instance_method,
:public_instance_methods, :public_method, :public_method_defined?,
:public_methods, :public_send, :remove_class_variable, :respond_to?,
:respond_to_missing?, :ri, :send, :singleton_class, :singleton_methods,
:superclass, :taint, :tainted?, :tap, :to_enum, :to_s, :trust, :untaint,
:untrust, :untrusted?]

Class.methods.class

=> Array

defined? Class.methods

=> "method"

Class.methods.uniq.sort[0].class

=> Symbol

Class.methods.uniq.sort[1].class

=> Symbol

defined? (Class.methods.uniq.sort[0])

=> "method"

defined? (Class.methods.uniq.sort[1])

=> "method"

Class.methods.uniq.sort[0] == Class.methods.uniq.sort[1]

=> false

How can be the same symbols(names) different ? Can somebody explain ?

If I define my own array of symbols, method 'uniq' works as expected,
because the same symbols are discarded.

[:one,:two,:three,:two,:four,:one].uniq

=> [:one, :two, :three, :four]

Can this be explained as a correct Ruby's behaviour or did I missed
something ?

Thanks.

David

···

--
Posted via http://www.ruby-forum.com/.

2

How can be the same symbols(names) different ? Can somebody explain ?

They are both methods, but they are not the same method:

Class.methods.uniq.sort[0]

=> :!

Class.methods.uniq.sort[1]

=> :!=

Regards,
Ammar

···

On Wed, Nov 17, 2010 at 6:47 PM, David Unric <dunric29a@gmail.com> wrote:

3

It really was a Wirble's issue the author was aware of. I find it an
essential flaw that changes IRB behaviour that leads to unexpected
results.

After digging in sources I made the following quick fix so now it should
display symbols properly. Besides equal-sign, there were
discarded/ignored also <, >, and ~ characters that may appear in symbol
names.

--- wirble-0.1.3/lib/wirble.rb.orig 2010-11-18 16:26:34.000000000 +0100
+++ wirble-0.1.3/lib/wirble.rb 2010-11-18 16:31:10.380273617 +0100
@@ -180,14 +180,20 @@
             end
           when :symbol
             case c
- # XXX: should have =, but that messes up foo=>bar
- when /[a-z0-9_!?]/
+ when /[a-z0-9_!?~<>]/
               val << c
             else
- yield :symbol_prefix, ':'
- yield state[-1], val
- state.pop; val = ''
- repeat = true
+ # peek ahead if equal sign is part of reference operator
'=>'
+ # and not of comparison method name at the same time
'<=>'
+ if (c == '=' and chars[i, 2].join == '=>' and lc != '<')
\
+ or (c != '=')
+ yield :symbol_prefix, ':'
+ yield state[-1], val
+ state.pop; val = ''
+ repeat = true
+ else
+ val << c
+ end
             end
           when :string
             case c

Did sent also to author of Wirble.

Take care.

···

--
Posted via http://www.ruby-forum.com/.

4

Ammar Ali wrote in post #962188:

How can be the same symbols(names) different ? Can somebody explain ?

They are both methods, but they are not the same method:

Class.methods.uniq.sort[0]

=> :!

Class.methods.uniq.sort[1]

=> :!=

Regards,
Ammar

Nope, they are same in my case:

Class.methods.uniq.sort[0]

=> :!

Class.methods.uniq.sort[1]

=> :!

But now I discovered it really would be an Wirble output issue:

">#{Class.methods.uniq.sort[0]}<"

=> ">!<"

">#{Class.methods.uniq.sort[1]}<"

=> ">!=<"

Regards

···

On Wed, Nov 17, 2010 at 6:47 PM, David Unric <dunric29a@gmail.com> > wrote:

--
Posted via http://www.ruby-forum.com/.

5

I'm not familiar with Wirble, but #uniq should not leave identical
items in the array.

Regards,
Ammar

···

On Wed, Nov 17, 2010 at 8:54 PM, David Unric <dunric29a@gmail.com> wrote:

Nope, they are same in my case:

Class.methods.uniq.sort[0]

=> :!

Class.methods.uniq.sort[1]

=> :!

But now I discovered it really would be an Wirble output issue:

">#{Class.methods.uniq.sort[0]}<"

=> ">!<"

">#{Class.methods.uniq.sort[1]}<"

=> ">!=<"