From: "Aleksi Niemelä" <aleksi.niemela@...>
Date: 2001-01-22T21:19:44+09:00
Subject: [ruby-talk:9712] Standard library reform

This a "reply" to a thread which was [ruby-talk:9710] Re: 101 Misconceptions
About Dynamic Languages, but I changed the subject since we're clearly
departing from that discussion.

Jean MICHEL wrote:

> I  think too  many things  are classes  were most  of the  
> functionality should have  been put  in mixins:
> most operations  on arrays or hashes should have been
> put in mixins, and  class IO should have been a mixin

I have to second that feeling. Although it's just right place for a
disclaimer. I don't know enough about Ruby to feel urge to change things, or
propose a change. But I'd like to listen the voice of the designer(s).

Matz, do you feel the current functionality should be repartitioned into
mixins, and composed back together, retaining most of the semantics and
being as much compatible as previously?

> Actually  I think it  is still not too  late to 
> reform  Ruby by pushing the  functionality in  mixins.

This kind of change could be characterized as a major one, thus the timing
of the change would be for Ruby 2.0. However, if we're rushing to change
things early and manage to keep backwards compatibility I see no reason to
object the change for 1.7 series already.

Therefore I'd like to hear matz and other core developer's opinions when the
possible redesign should be done.

> As  far as I  can see this would change the language
> in a perfectly upward compatible way.

Well, I'm not all that sure. I guess we can keep most of the feature like
they're now, but I'd guess 

  ruby -e'p Array.ancestors'
  [Array, Enumerable, Object, Kernel]

would give different answer if we're adding some mix-ins. Having even one
snippet around which relies on this array's contents will make the change
incompatible. OTOH, as far as I can see the possible problems from this
change are rare and quite possibly harmless. And I think one can expect some
changes to the old source code even for minor version upgrades. (Says one
who spent some time fixing //p to //m yesterday... :)

	- Aleksi