I’m in an irb session where i have a lot of modules loaded. All of the
modules have a common parent, ‘Thoth’. So, i’m referring to lots of
classes called ‘Thoth::Post’, ‘Thoth::Tag’, ‘Thoth::Page’ etc.
To save some typing, i’d just like to refer to these classes as Post,
Tag or Page. Is there a way i can sort of ‘move into’ the Thoth module,
so i don’t have to keep namespacing the classes all the time?
Sorry if i’m not explaining this very well, i’m possibly showing off my
ignorance about the relationship between classes and modules here…
I’m in an irb session where i have a lot of modules loaded. All of the
modules have a common parent, ‘Thoth’. So, i’m referring to lots of
classes called ‘Thoth::Post’, ‘Thoth::Tag’, ‘Thoth::Page’ etc.
To save some typing, i’d just like to refer to these classes as Post,
Tag or Page. Is there a way i can sort of ‘move into’ the Thoth module,
so i don’t have to keep namespacing the classes all the time?
Sorry if i’m not explaining this very well, i’m possibly showing off my
ignorance about the relationship between classes and modules here…
You can use the irb command inside irb:
irb(main):001:0> module M; X=1; end
=> 1
irb(main):002:0> irb M
irb#1(M):001:0> X
=> 1
This puts you in a context where the object you’ve irb’d is self. (Use
‘exit’ to get back to your top-level irb session.) You could also
include the module, or reopen it. There are some differences among
these techniques, but somewhere in there you can probably find
something.
Yeah, i use irb inside irb a lot, it’s really useful when i’m puzzling
over an instance method for example (usually in the rails console). It
didn’t occur to me to use it here (obviously).
Using ‘include’ seems better in this case as i still have the more
general scope - i’m using irb in this case like i would normally use the
rails console, but using Thoth (a framework for blogs) rather than
Rails. So, including the module rather than moving into it seems more
like my general app environment, which i guess is what you want in a
console like this. Would you agree?
like my general app environment, which i guess is what you want in a
console like this. Would you agree?
It sounds OK, as long as there’s nothing in Thoth that’s going to be
masked by what’s already in Object. For example, if there’s a
Thoth::String, you won’t see it:
irb(main):001:0> module M; String=1; end
=> 1
irb(main):002:0> include M
=> Object
irb(main):003:0> String
=> String
as opposed to:
irb(main):004:0> irb M
irb#1(M):001:0> String
=> 1
String.new.class
a weird way.
When you do irb M, you’re putting M before all else in the constant
resolution path. So String.new is really M::String.new. “hello” is
still a ::String (top-level, core String class), because the existence
of M::String does not affect the behavior of the literal quotation
marks (which create a ::String).
String.new.class
a weird way.
When you do irb M, you’re putting M before all else in the constant
resolution path. So String.new is really M::String.new. “hello” is
still a ::String (top-level, core String class), because the existence
of M::String does not affect the behavior of the literal quotation
marks (which create a ::String).
David
ah, ok. I thought that
“hello”
was the same thing as
String.new(“hello”)
, though? Or, does it bypass the usual lookup table for methods?
Am Samstag 20 Juni 2009 18:36:46 schrieb David A. Black:
It bypasses.
And if it didn’t, it would very likely be the same thing as
::String.new(“hello”), not String.new(“hello”), i.e. it would
use the full path to the constant, not the relative path,
to avoid ambiguity. At least I would consider anything else
to be confusing.
