Feature #12715
Updated by nobu (Nobuyoshi Nakada) over 8 years ago
Hello - I try to be somewhat short, as much as possible.
In ruby we have classes and modules. We can do module Foo; class Bar
and also class Foo; module Bar. Both is slightly different, also in
regards to errors you get when you try to extend either of these
two. The problem here is that, when we wish to add new behaviour to
a class or a module, we may have to know whether it is a class or a
module explicitely.
If we do not specify this correctly so, we may get an error like this
one here:
Bar is not a class (TypeError)
I believe, however had, that it should not be absolutely mandatory to
HAVE to know the type of a "class" or a "module", in particular not at
runtime when all you want to do is add new behaviour to an already
existing class or module. And if you know that class or module too.
I also believe that the current behaviour may not be changed for
several reasons; backwards compatibility; also a user may have
made a mistake or changed some class/module lateron, so we may
have to catch these errors too. I have run into this every now
and then e. g. when I had a standalone class in a project, but
lateron modified this class to become a subclass of another class;
then I also have to change the definitions for that class being
a subclass in other .rb files (I tend to create several .rb files
if my code becomes large, and some classes become really quite
huge in some of my projects; ~more than 200 lines of code is
already monster-sized in my opinion :) ).
It would be nice if we could, however had, have another way to
modify the behaviour, in ruby.
I do not have a good suggestion here, so please, when you read
the following, keep in mind that I am aware that this is not
really perfect either - it just should serve as an illustration.
I will omit the "end"s to be more succinct.
```ruby
module Foo; class Bar; def self.hi; puts 'hi from method hi()'
```
Ok, now I want to modify inner class Bar without having to care
whether it is a class or a module so I will use the word "modify"
as well:
```ruby
modify Foo::Bar; def self.new_method; puts 'a new method!'
```
Here I would have used the (then new) keyword "modify".
I think the name somewhat fits. One could use other names, perhaps.
```ruby
adapt Foo::Bar; def self.new_method; puts 'a new method!'
mod Foo::Bar; def self.new_method; puts 'a new method!'
change Foo::Bar; def self.new_method; puts 'a new method!'
update Foo::Bar; def self.new_method; puts 'a new method!'
```
Though I like modify as name more than the other variants.
I think that this probably has not a huge chance to be implemented,
most likely not for ruby 3.x; perhaps in the very distant future
towards ruby 4.x?
But I think the main reason why I actually wrote this suggestion
here, even though it probably does not have a huge chance to be
implemented, is mostly just to point out that I think I should not
have to be explicit about the class versus module dichotomy here when
all I want to do is really just add a class/module method (singleton
method?) to in particular already existing ruby classes/modules.
I do have to know whether it is a class or a module right now,
because in one way, it will work, in the other it will fail.
So my suggestion above would eliminate the possibility of the error,
simply by telling ruby "no matter if it is a class or a module,
simply add the code to it" and ruby can infer internally whether
it is a class or a module via a check.
I am not sure if any of this makes sense - I may have forgotten
some other things too - but thank you for reading it anyway!