Forum: Ruby how do you create a large number of irb commands?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
8f0660cdc9f5d91c7d97456f8f0be8c7?d=identicon&s=25 ghorner (Guest)
on 2009-05-13 17:11
(Received via mailing list)
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/9ca4e66f2...
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
8f0660cdc9f5d91c7d97456f8f0be8c7?d=identicon&s=25 cldwalker (Guest)
on 2009-05-13 17:51
(Received via mailing list)
On May 13, 11:07 am, ghorner <gabriel.hor...@gmail.com> wrote:
> * Use irb's internal command system i.e. self.def_extend_command() 
inhttp://github.com/rubyspec/matzruby/blob/9ca4e66f2......
> 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
8f0660cdc9f5d91c7d97456f8f0be8c7?d=identicon&s=25 cldwalker (Guest)
on 2009-05-15 00:05
(Received via mailing list)
On May 13, 11:49 am, cldwalker <gabriel.hor...@gmail.com> wrote:
> > * Include modules into the default irb object. However this has the
> > needed functionality. Since defining methods in the irb object lacks
> 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?
This topic is locked and can not be replied to.