'move into' a module's namespace in irb

[Max Williams]

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:ost', 'Thoth::Tag', 'Thoth:age' 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...

thanks, max

 

[David A. Black]

Hi --

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:ost', 'Thoth::Tag', 'Thoth:age' 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.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Now available: The Well-Grounded Rubyist (http://manning.com/black2)
"Ruby 1.9: What You Need To Know" Envycasts with David A. Black
http://www.envycasts.com

 

[Max Williams]

I just tried

include Thoth

in irb and that seems to have worked. Seems pretty obvious in
retrospect.

 

[Max Williams]

Hi David

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?

Thanks
max

 

[David A. Black]

Hi --

Hi David

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?

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


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Now available: The Well-Grounded Rubyist (http://manning.com/black2)
"Ruby 1.9: What You Need To Know" Envycasts with David A. Black
http://www.envycasts.com

 

[Max Williams]

aha...i was just playing with this in irb and found something puzzling -
would you mind, while we're on this subject, explaining it to me?

#here, "hello" and String.new are the same class=> String

#here, they're not the same class=> M::String

It looks like the core String and the module's version are colliding in
a weird way.

 

[David A. Black]

Hi --

aha...i was just playing with this in irb and found something puzzling -
would you mind, while we're on this subject, explaining it to me?


#here, "hello" and String.new are the same class
=> String

#here, they're not the same class
=> M::String

It looks like the core String and the module's version are colliding in
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

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Now available: The Well-Grounded Rubyist (http://manning.com/black2)
"Ruby 1.9: What You Need To Know" Envycasts with David A. Black
http://www.envycasts.com

 

[Max Williams]

Hi --


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?

 

[David A. Black]

Hi --

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?

It bypasses. The literal constructors aren't hooked in to the
method-based constructors:

irb(main):001:0> def Array.new; "blah"; end
=> nil
irb(main):002:0> Array.new
=> "blah"
irb(main):003:0> []
=> []

etc.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Now available: The Well-Grounded Rubyist (http://manning.com/black2)
"Ruby 1.9: What You Need To Know" Envycasts with David A. Black
http://www.envycasts.com

 

[Max Williams]

ah, that all makes sense then

Thanks for all your help David.

cheers
max

 

[Sebastian Hungerecker]

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.

 

[Rick DeNatale]

It bypasses. The literal constructors aren't hooked in to the
method-based constructors:

Also consider that if

"Hello"
were equivalent to

String.new("Hello")

it would in turn be equivalent to
String.new(String.new("Hello"))
and
String.new(String.new(String.new("Hello")))
etc. ad infinitum, ad nauseam.

So literals need to be reified at parse time to avoid this infinite regress=
ion.

--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale