How do you create a large number of irb commands?

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/blob/9ca4e66f27e2563512afdd4c70afab34d80d513d/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

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

···

On May 13, 11:07 am, ghorner <gabriel.hor...@gmail.com> 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

So I guess *no one* creates commands in irb?

···

On May 13, 11:49 am, cldwalker <gabriel.hor...@gmail.com> wrote:

On May 13, 11:07 am, ghorner <gabriel.hor...@gmail.com> 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