---2049402039-448375802-11523260037016
Content-Type: MULTIPART/MIXED; BOUNDARY="-2049402039-448375802-1152326003=:27016"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---2049402039-448375802-11523260037016
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi --

On Fri, 7 Jul 2006, Patrick Hurley wrote:

> On 7/6/06, Damaris Fuentes <dfl_maradentro / yahoo.es> wrote:
>>  My question isif I run
>> this file with the new definitions..., does the core String class of
>> Ruby remain changed forever?  I dunno©Ęs not this feature a little
>> dangerous?
>
> "Ruby, you'll shoot your eye out"
>
> It is changed until you unchange it, or the interpreter stops -- not
> forever. But yes changing core classes is "dangerous." But so are most
> things worth doing or having. To quote another movie:
>
> "with great power comes great responsibility"

I keep hearing that in the context of this question, but I haven't
figured out how it translates into practical advice.  I think it's
been used to argue both that one should not re-open core classes, and
that it's OK to do so as long as one is willing to live with
unpredictable runtime failure :-)

> Write unit tests and enjoy.

Testing doesn't address the main problem associated with core changes,
though, namely how they'll affect code that doesn't know about them.
For example, if someone writes code that depends on certain bang
methods returning nil when their receivers don't change, and then
someone "fixes" them so that they return their receivers, something is
likely to break at an unexpected (and unlikely to have been pinpointed
by tests) point.

I tend to think that core changes are surrounded by too much mystique
-- as if they were different from any other code change.  If I write a
library and someone uses it, and that person redefines a method so
that it does something different and produces a different return
value, they can't expect the rest of my library to work.  The Ruby
core is our communal library, and the same conditions apply.

Of course not every core change is in this category.  Pass-through
method overrides, where the original method ends up getting called
anyway, are relatively innocuous, and one could even imagine chaining
them without ill effect.  Additive ones (completely new methods) are
*probably* usually safe... until two people add differently-behaving
methods with the same name.


David

-- 
  "To fully realize the potential of Rails, it's crucial that you take
    the time to fully understand Ruby--and with "Ruby for Rails" David
       has provided just what you need to help you achieve that goal."
       -- DAVID HEINEMEIER HANSSON, in the foreword to RUBY FOR RAILS.
  Complete foreword & sample chapters at http://www.manning.com/black!
---2049402039-448375802-11523260037016--
---2049402039-448375802-11523260037016--