Re: Extending ruby classes - Against new methods?

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/


> 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. :)
-- 
Posted via http://www.ruby-forum.com/.