how do you create a large number of irb commands?

Discussion in 'Ruby' started by ghorner, May 13, 2009.

  1. ghorner

    ghorner Guest

    I'm wondering what you all consider the best way for creating a large
    number of irb commands. By commands I'm referring to methods for the
    default irb object like irb,fg and jobs. Here are some of the
    different ways that come to mind:

    * Extend the default irb object with modules.
    * Include modules into the default irb object. However this has the
    nasty side effect of making those methods accessible to all objects.
    * Just define methods in the default irb object. Simple and seems to
    be the common way in irbrc's.
    * Use irb's internal command system i.e. self.def_extend_command() in
    http://github.com/rubyspec/matzruby...d4c70afab34d80d513d/lib/irb/extend-command.rb
    Seems like overkill.

    To me the only serious options are extending or just defining the
    method. By extending I get an ancestry trace on where commands came
    from which is important when dealing with a large number of commands.
    Also, if i do switch subsessions or workspaces I can just extend in
    needed functionality. Since defining methods in the irb object lacks
    the ancestry trace and the ability to reuse them in other context, my
    vote is for extending.

    Thoughts?

    Gabriel
    ghorner, May 13, 2009
    #1
    1. Advertising

  2. ghorner

    cldwalker Guest

    On May 13, 11:07 am, ghorner <> wrote:
    > I'm wondering what you all consider the best way for creating a large
    > number of irb commands. By commands I'm referring to methods for the
    > default irb object like irb,fg and jobs. Here are some of the
    > different ways that come to mind:
    >
    > * Extend the default irb object with modules.
    > * Include modules into the default irb object. However this has the
    > nasty side effect of making those methods accessible to all objects.
    > * Just define methods in the default irb object. Simple and seems to
    > be the common way in irbrc's.
    > * Use irb's internal command system i.e. self.def_extend_command() inhttp://github.com/rubyspec/matzruby/blob/9ca4e66f27e2563512afdd4c70af...
    > Seems like overkill.
    >
    > To me the only serious options are extending or just defining the
    > method. By extending I get an ancestry trace on where commands came
    > from which is important when dealing with a large number of commands.
    > Also, if i do switch subsessions or workspaces I can just extend in
    > needed functionality. Since defining methods in the irb object lacks
    > the ancestry trace and the ability to reuse them in other context, my
    > vote is for extending.
    >
    > Thoughts?
    >
    > Gabriel


    I forgot to mention the option of commands as private methods in
    Kernel space. Like the include option, I think it's too dirty as it
    gives all objects access to those methods through send(). Although
    this doesn't matter for a couple of commands, it could lead to some
    dangerous side effects for many commands. My vote is still with
    extending modules.

    Gabriel
    cldwalker, May 13, 2009
    #2
    1. Advertising

  3. ghorner

    cldwalker Guest

    On May 13, 11:49 am, cldwalker <> wrote:
    > On May 13, 11:07 am, ghorner <> wrote:
    >
    >
    >
    > > I'm wondering what you all consider the best way for creating a large
    > > number of irb commands. By commands I'm referring to methods for the
    > > default irb object like irb,fg and jobs. Here are some of the
    > > different ways that come to mind:

    >
    > > * Extend the default irb object with modules.
    > > * Include modules into the default irb object. However this has the
    > > nasty side effect of making those methods accessible to all objects.
    > > * Just define methods in the default irb object. Simple and seems to
    > > be the common way in irbrc's.
    > > * Use irb's internal command system i.e. self.def_extend_command() inhttp://github.com/rubyspec/matzruby/blob/9ca4e66f27e2563512afdd4c70af...
    > > Seems like overkill.

    >
    > > To me the only serious options are extending or just defining the
    > > method. By extending I get an ancestry trace on where commands came
    > > from which is important when dealing with a large number of commands.
    > > Also, if i do switch subsessions or workspaces I can just extend in
    > > needed functionality. Since defining methods in the irb object lacks
    > > the ancestry trace and the ability to reuse them in other context, my
    > > vote is for extending.

    >
    > > Thoughts?

    >
    > > Gabriel

    >
    > I forgot to mention the option of commands as private methods in
    > Kernel space. Like the include option, I think it's too dirty as it
    > gives all objects access to those methods through send(). Although
    > this doesn't matter for a couple of commands, it could lead to some
    > dangerous side effects for many commands. My vote is still with
    > extending modules.
    >
    > Gabriel


    So I guess *no one* creates commands in irb?
    cldwalker, May 14, 2009
    #3
    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. Sam Stephenson
    Replies:
    1
    Views:
    224
    Andrew Walrond
    Jun 18, 2005
  2. Replies:
    1
    Views:
    156
    Florian Groß
    Oct 26, 2005
  3. anne001
    Replies:
    1
    Views:
    267
    anne001
    Jun 27, 2006
  4. Replies:
    4
    Views:
    99
  5. Andre Nathan

    Shell commands in irb

    Andre Nathan, Oct 16, 2006, in forum: Ruby
    Replies:
    6
    Views:
    117
    Wayne Vucenic
    Oct 17, 2006
Loading...

Share This Page