The class-extention in module Bb does not work, how do I solve this>??
When you say
module Aa
class Fixnum
This is not the same Fixnum as the top-level Fixnum. This is
Aa::Fixnum, of which 10 is not an instance. You can refer to a
top-level constant prefixing it with “::”. So:
A Ruby integer is always an instance of the built-in classes ::Fixnum or
::Bignum. You cannot have different integers depending on the
surrounding module.
This is actually a good thing, because you certainly don’t want such
elementary objects to behave context-dependend. Imagine you make a
calculation and get different results for different modules.
I would generally avoid messing with the built-in classes. Sometimes it
does make sense to add convenience methods, but something like
“print_times” isn’t really worth it in my opinion.
So its better to not extend built-in classes, and ::Fixnum
has nothing todo with Module::Fixnum , in the latter it’s just
a custom name for some class?
But if some other .rb uses the same name for its Fixnum class extension,
including different methods, there will be collision ??
Yes. And with that you have exactly nailed one of the major reasons
why your change is not a good idea. There are actually more
reasons, e.g. that a number has no job in containing printing methods.
So I tried to wrap my class extension in a module like this:
module Aa
class Fixnum
def times_print(str)
times { puts str }
end
end
end
Here you create a new class ::Aa::Fixnum which is totally unrelated to
::Fixnum…
module Bb
include Aa
def self.test
10.times_print('foo')
end
test
end
The class-extention in module Bb does not work, how do I solve this>??
So its better to not extend built-in classes, and ::Fixnum
has nothing todo with Module::Fixnum , in the latter it’s just
a custom name for some class?
So its better to not extend built-in classes, and ::Fixnum
has nothing todo with Module::Fixnum , in the latter it’s just
a custom name for some class?
A Ruby integer is always an instance of the built-in classes ::Fixnum or
::Bignum. You cannot have different integers depending on the
surrounding module.
This is actually a good thing, because you certainly don’t want such
elementary objects to behave context-dependend.
I think that’s exactly what the proposed ruby 2.0 “refinements” are
intended to do.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.