2009/4/24 Marc Heiler <shevegen / linuxmail.org>:
> 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?  ¨Âåóôòéãôéîç
>> 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/

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

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/