# Extending ruby classes - Against new methods?

**URL:** <https://www.ruby-forum.com/t/extending-ruby-classes-against-new-methods/166332>\
**Category:** Ruby\
**Created:** [April 23, 2009, 11:30pm UTC](https://www.ruby-forum.com/t/extending-ruby-classes-against-new-methods/166332 "2009-04-23T23:30:22Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![quik77](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/dec6dc/32.png) [@quik77](https://www.ruby-forum.com/u/quik77)\
**Post date:** [April 23, 2009, 11:30pm UTC](https://www.ruby-forum.com/t/extending-ruby-classes-against-new-methods/166332/1 "2009-04-23T23:30:22Z")

</div>

Hi,

Recently I added  
def strip!  
to class Array. I found that I needed it, and some of my arrays were  
collection of strings having whitespace. It was trivial, and I thought  
this could be part of standard ruby. But I remember that there was some  
issue, i.e. matz not wanting to have too many methods or similar. We  
also have the facets library (but I found it to be too big, or,  
depending on the viewpoint one has, should rather be part of the  
language itself)

Anyway, my question is - is it true that new methods are rarely added to  
ruby?

The String class is really rather big compared to the Array class, and i  
figured that people will work with string objects most of the time  
(compared to Array objects or Hash objects) - they are useful, but I  
think all through rubyland (think all virtual ruby objects), there would  
be more string objects than array objects etc…

---

<div class="post-metadata">

**Author:** ![quik77](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/dec6dc/32.png) [@quik77](https://www.ruby-forum.com/u/quik77)\
**Post date:** [April 24, 2009, 1:07am UTC](https://www.ruby-forum.com/t/extending-ruby-classes-against-new-methods/166332/2 "2009-04-24T01:07:58Z")

</div>

Marc H. wrote:

> Anyway, my question is - is it true that new methods are rarely  
> added to ruby?

I don’t know; but, after reading your post I sure hope it’s true. I  
wouldn’t want your strip! added to Ruby.

I can think of at least four very different things to expect an  
Array#strip! to do. Why add foggy methods to Ruby?

> The String class is really rather big compared to the Array class

So?

It isn’t wastful to have classes with very few methods. If computers had  
a “5$ for the first 20 methods; Any method above 20 is free” rule then  
indeed it’d be wasteful to have little classes. But it isn’t the case.

---

<div class="post-metadata">

**Author:** ![quik77](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/dec6dc/32.png) [@quik77](https://www.ruby-forum.com/u/quik77)\
**Post date:** [April 24, 2009, 8:37am UTC](https://www.ruby-forum.com/t/extending-ruby-classes-against-new-methods/166332/3 "2009-04-24T08:37:30Z")

</div>

On 23.04.2009 23:30, Marc H. wrote:

> Recently I added  
> def strip!  
> to class Array. I found that I needed it, and some of my arrays were  
> collection of strings having whitespace.

Why didn’t you choose to add this to module Enumerable? Restricting  
this to Arrays does not seem to make much sense.

> It was trivial, and I thought  
> this could be part of standard ruby.

The reason to include something in standard Ruby is not the ease of  
implementation but rather the usefulness for a wide audience and many  
uses of the class. Since your case of stripping all strings in a  
collection seems to be a rather esoteric case. Remember that there can  
be any type of object in such a collection! When deciding on adding  
something to a core class you should look at the outside.

> Anyway, my question is - is it true that new methods are rarely added to  
> ruby?

Do you mean by the core team or ad hoc by application programmers?  
Modification of core classes is done cautiously (seldom) while  
application programmers seem to often augment core classes with  
additional methods.

> The String class is really rather big compared to the Array class, and i  
> figured that people will work with string objects most of the time

This totally depends on the application case. Side note: my impression  
is that people tend to create too few classes (common example: methods  
are added to Hash instead of creating a class whose instances contain a  
Hash instance and use it appropriately).

> (compared to Array objects or Hash objects) - they are useful, but I  
> think all through rubyland (think all virtual ruby objects), there would  
> be more string objects than array objects etc…

I am not sure I get your point. The sole fact that there are more  
instances of class X vs. class Y does not tell me anything about what  
methods should be added to X or Y.

Kind regards

robert

---

<div class="post-metadata">

**Author:** ![quik77](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/dec6dc/32.png) [@quik77](https://www.ruby-forum.com/u/quik77)\
**Post date:** [April 24, 2009, 1:38pm UTC](https://www.ruby-forum.com/t/extending-ruby-classes-against-new-methods/166332/4 "2009-04-24T13:38:31Z")

</div>

2009/4/24 Marc H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> This is no problem if everyone works alone, but when you _do_ extend  
> core classes a lot and rely on solutions which you think are shorter and  
> more elegant, people are quick to shout “monkey patching” or refuse to  
> adopt another style. The more projects involved, the more different  
> styles involved, the higher the chances of conflict. For instance, I do  
> not like code parts involving @@, $ or lambdas.

The context is important: as long as you do it for a simply script or  
a small project only, then criteria for change of core classes can be  
far less restricted than for example if you write a library that you  
intend to make public.

> > I can think of at least four very different things to expect an  
> > Array#strip! to do. Why add foggy methods to Ruby?
> 
> Quite obviously .strip! on Array simply applies what .strip! does on  
> Strings.

This is by far not obvious because even Array instances with no  
Strings in them (but other objects) will have it.

The semantics of strip! in a core class should not rely on features of  
potential collection members. Your Array#strip! will fail as soon as  
there is a single instance in the Array which does not respond to  
strip!. That way you have introduced a bad dependency.

> > Why didn’t you choose to add this to module Enumerable? Restricting  
> > this to Arrays does not seem to make much sense.
> 
> Quite frankly, I didn’t need it outside of Strings or Arrays so far.  
> Maybe it should be part of Enumerable, but I really have needed it  
> outside there yet. It seems easier to add it only where it is needed.

There is no difference in effort between

class Array  
def strip!  
each {|s| s.strip!}  
end  
end

module Enumerable  
def strip!  
each {|s| s.strip!}  
end  
end

Granted, “Enumerable” has a few more characters to type than “Array”…

> As  
> written above the only problem is when I release projects and use my own  
> style here which extends ruby classes. How do other people solve this?  
> Not extend ruby core classes?
> 
> This would be the logical solution for me, but it quite makes the  
> flexibility of ruby less usable if everyone restricts oneself to what is  
> inside the language only, because they would have to make sure that  
> their code works with all their “personal extensions” as well (and add  
> that to projects).

You can still have personal extensions with the same functionality.  
You just need to put it into a function.

def strip!(enum)  
enum.each {|s| s.strip!}  
end

Now you do not clutter the namespace of core classes.

> > The reason to include something in standard Ruby is not the ease of  
> > implementation but rather the usefulness for a wide audience and many  
> > uses of the class.
> 
> But how is this usefulness measured?

The fact that your strip method works only for collections that solely  
contains String instances (or more precisely, instances which respond  
to strip! is a killer criterion). The method simply lacks  
universality.

> Take the facets library for  
> example, how many people will use it? I mean in theory it sounds like a  
> great idea, but on the other hand if noone would use it it would make  
> the project quite … useless. [http://facets.rubyforge.org/](http://facets.rubyforge.org/)

Facets is a library you can consciously use - or not. If your  
suggestion to place this method in the core lib would be followed  
everybody would have to live with it.

> > This totally depends on the application case.
> 
> True. But for the perhaps 5000 .rb files I wrote so far, most objects  
> dealt  
> with strings, even if they are stored inside hashes or arrays.

This tells me that you either work in a very specific domain or that  
you overuse String. 🙂

> I can’t really say how it is for other projects, but I dare claim now  
> that strings are the core everywhere. Bold statements catch attention 🙂

Frankly, I do not understand what this has to do with your suggested  
change of class Array (or module Enumerable).

> > The sole fact that there are more instances of class X vs. class Y  
> > does not tell me anything about what methods should be added to X or Y.
> 
> I guess I tried to make a point that different classes in ruby are more  
> useful than others. Does this influence decisions to add or remove  
> methods at all?  
> I still think the String class is really the core of ruby as far as  
> everyday useage is concerned, and thus more important than let’s say  
> Array.

So you say, we can more easily introduce inconsistencies in Array  
because it is less used? (_If_ it is less used, I doubt it.)

> I am actually interested in the complete useage patterns for all kind of  
> ruby objects, and whether people rather subclass and extend, or directly  
> extend core classes to solve a given problem at hand.
> 
> As I said, I guess if I never want to work on projects which other  
> people can use too, I have no problem at all, because my code is fine  
> already no matter what style I use (after all, I know my own code). But  
> if 1000 people have 1000 projects, it seems as if the netto result is a  
> huge spaghetti design, where others have partially called it monkey  
> patching or worse.

That’s the exact reason why you should be careful with changing core  
classes if your code is targeted at a wider audience.

> It seems to me that people are happier to _not_ have a  
> dependency on something, if they can avoid it.

That’s a general rule because more dependencies create complexer code  
and more potential for bugs.

Cheers

robert

---

<div class="post-metadata">

**Author:** ![quik77](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/dec6dc/32.png) [@quik77](https://www.ruby-forum.com/u/quik77)\
**Post date:** [April 24, 2009, 11:57am UTC](https://www.ruby-forum.com/t/extending-ruby-classes-against-new-methods/166332/5 "2009-04-24T11:57:21Z")

</div>

Hmm, replying to two in one message now 😉

> I wouldn’t want your strip! added to Ruby.

See, exactly that is the dilemma and is one reason why `facets` is a  
part of outside Ruby. The same could be reasoned for 1000 different use  
cases as well, and the netto result will be that everyone has its own  
share of coding style.

This is no problem if everyone works alone, but when you _do_ extend  
core classes a lot and rely on solutions which you think are shorter and  
more elegant, people are quick to shout “monkey patching” or refuse to  
adopt another style. The more projects involved, the more different  
styles involved, the higher the chances of conflict. For instance, I do  
not like code parts involving @@, $ or lambdas.

Let me put it another way. A ruby project I know of - which is somewhat  
successful - is happy for patches contributed by other people. This will  
lead to different styles, for instance one author used .kind\_of? whereas  
pretty much everyone else preferred .is\_a?

> I can think of at least four very different things to expect an  
> Array#strip! to do. Why add foggy methods to Ruby?

Quite obviously .strip! on Array simply applies what .strip! does on  
Strings.

> It isn’t wastful to have classes with very few methods.

The point is that I regard the String class as more central to ruby than  
Array class as far as everyday usage is concerned. This is not about  
being wasteful or not.

> Why didn’t you choose to add this to module Enumerable? Restricting  
> this to Arrays does not seem to make much sense.

Quite frankly, I didn’t need it outside of Strings or Arrays so far.  
Maybe it should be part of Enumerable, but I really have needed it  
outside there yet. It seems easier to add it only where it is needed. As  
written above the only problem is when I release projects and use my own  
style here which extends ruby classes. How do other people solve this?  
Not extend ruby core classes?

This would be the logical solution for me, but it quite makes the  
flexibility of ruby less usable if everyone restricts oneself to what is  
inside the language only, because they would have to make sure that  
their code works with all their “personal extensions” as well (and add  
that to projects).

> The reason to include something in standard Ruby is not the ease of  
> implementation but rather the usefulness for a wide audience and many  
> uses of the class.

But how is this usefulness measured? Take the facets library for  
example, how many people will use it? I mean in theory it sounds like a  
great idea, but on the other hand if noone would use it it would make  
the project quite … useless. [http://facets.rubyforge.org/](http://facets.rubyforge.org/)

> Do you mean by the core team or ad hoc by application programmers?

Core team of course. The application programmers created facets, after  
all … 😉

> Modification of core classes is done cautiously (seldom) while  
> application programmers seem to often augment core classes with  
> additional methods.

Does anyone know how Rails is doing this? Do they extend core classes  
heavily?

> This totally depends on the application case.

True. But for the perhaps 5000 .rb files I wrote so far, most objects  
dealt  
with strings, even if they are stored inside hashes or arrays.  
I can’t really say how it is for other projects, but I dare claim now  
that strings are the core everywhere. Bold statements catch attention 🙂

> my impression is that people tend to create too few classes  
> (common example: methods are added to Hash instead of  
> creating a class whose instances contain a Hash instance  
> and use it appropriately).

I would instantly believe you. I myself used to create huge classes  
years ago until I realized that classes in itself are quite good at  
simplifying problems by divide&conquer. If it becomes smaller, it  
seems easier to manage.

> The sole fact that there are more instances of class X vs. class Y  
> does not tell me anything about what methods should be added to X or Y.

I guess I tried to make a point that different classes in ruby are more  
useful than others. Does this influence decisions to add or remove  
methods at all?  
I still think the String class is really the core of ruby as far as  
everyday useage is concerned, and thus more important than let’s say  
Array.  
But on the other hand, how many people subclass String objects, and how  
many people subclass Array or Hashes?

I am actually interested in the complete useage patterns for all kind of  
ruby objects, and whether people rather subclass and extend, or directly  
extend core classes to solve a given problem at hand.

As I said, I guess if I never want to work on projects which other  
people can use too, I have no problem at all, because my code is fine  
already no matter what style I use (after all, I know my own code). But  
if 1000 people have 1000 projects, it seems as if the netto result is a  
huge spaghetti design, where others have partially called it monkey  
patching or worse.

Regards,  
Marc

PS: To be honest, I can not think of any project that did  
require ‘facets’  
so far. It seems to me that people are happier to _not_ have a  
dependency on something, if they can avoid it. If anyone knows projects  
that use or require facets, let me know people - the bigger the project,  
the better for me to have a look. 🙂