'move into' a module's namespace in irb

Discussion in 'Ruby' started by Max Williams, Jun 20, 2009.

  1. Max Williams

    Max Williams Guest

    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...

    thanks, max
    --
    Posted via http://www.ruby-forum.com/.
     
    Max Williams, Jun 20, 2009
    #1
    1. Advertising

  2. 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::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.


    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, Jun 20, 2009
    #2
    1. Advertising

  3. Max Williams

    Max Williams Guest

    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/.
     
    Max Williams, Jun 20, 2009
    #3
  4. Max Williams

    Max Williams Guest

    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/.
     
    Max Williams, Jun 20, 2009
    #4
  5. 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
     
    David A. Black, Jun 20, 2009
    #5
  6. Max Williams

    Max Williams Guest

    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/.
     
    Max Williams, Jun 20, 2009
    #6
  7. 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, Jun 20, 2009
    #7
  8. Max Williams

    Max Williams Guest

    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/.
     
    Max Williams, Jun 20, 2009
    #8
  9. 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
     
    David A. Black, Jun 20, 2009
    #9
  10. Max Williams

    Max Williams Guest

    Max Williams, Jun 20, 2009
    #10
  11. Am Samstag 20 Juni 2009 18:36:46 schrieb David A. Black:
    > On Sun, 21 Jun 2009, Max Williams wrote:
    > > 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.


    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.
     
    Sebastian Hungerecker, Jun 20, 2009
    #11
  12. On Sat, Jun 20, 2009 at 12:36 PM, David A. Black<> wrote:
    > On Sun, 21 Jun 2009, Max Williams wrote:
    >> ah, ok. =A0I thought that
    >>
    >> "hello"
    >>
    >> was the same thing as
    >>
    >> String.new("hello")
    >>
    >> , though? =A0Or, does it bypass the usual lookup table for methods?

    >
    > 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
     
    Rick DeNatale, Jun 20, 2009
    #12
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jason Heyes
    Replies:
    1
    Views:
    452
    Woebegone
    Nov 19, 2004
  2. Ulrich Dorda
    Replies:
    4
    Views:
    444
  3. Sam Stephenson
    Replies:
    1
    Views:
    228
    Andrew Walrond
    Jun 18, 2005
  4. Replies:
    1
    Views:
    161
    Florian GroƟ
    Oct 26, 2005
  5. anne001
    Replies:
    1
    Views:
    277
    anne001
    Jun 27, 2006
Loading...

Share This Page