«

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
--
Posted via http://www.ruby-forum.com/.

Hi --

On Sat, 20 Jun 2009, Max Williams wrote:

> 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

I just tried

include Thoth

in irb and that seems to have worked. Seems pretty obvious in
retrospect.
--
Posted via http://www.ruby-forum.com/.

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
--
Posted via http://www.ruby-forum.com/.

Hi --

On Sat, 20 Jun 2009, Max Williams wrote:

> 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

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?

>> module M; class String; def how_long; "could be anything"; end; end; end

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

#here, they're not the same class
>> irb M
>> "hello".class
=> String
>> String.new.class
=> M::String

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


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

Hi --

On Sun, 21 Jun 2009, Max Williams wrote:

> 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?
>
>>> module M; class String; def how_long; "could be anything"; end; end; end
>
> #here, "hello" and String.new are the same class
>>> include M
> => Object
>>> "hello".class
> => String
>>> String.new.class
> => String
>
> #here, they're not the same class
>>> irb M
>>> "hello".class
> => String
>>> String.new.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

David A. Black wrote:
> Hi --
>
> On Sun, 21 Jun 2009, Max Williams wrote:
>
>>>> 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?
--
Posted via http://www.ruby-forum.com/.

Hi --

On Sun, 21 Jun 2009, Max Williams wrote:

> David A. Black wrote:
>> Hi --
>>
>> On Sun, 21 Jun 2009, Max Williams wrote:
>>
>>>>> 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?

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

ah, that all makes sense then

Thanks for all your help David.

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