Ruby's inconsistency or an IRB issue ?

D

David Unric

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.
=> [:!, :!, :!, :, :, :=>, :, :, :, :, :, :__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?, :eek:bject_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.
[:eek:ne,:two,:three,:two,:four,:eek:ne].uniq
=> [:eek:ne, :two, :three, :four]

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

Thanks.

David
 
D

David Unric

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
 
D

David Unric

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

class#methods how ? 3

Members online

Forum statistics

Threads
473,982
Messages
2,570,190
Members
46,740
Latest member
AdolphBig6

Latest Threads

Top