Patrick Hurley
7/10/2006 8:32:00 PM
On 7/7/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
> On Fri, 7 Jul 2006, Patrick Hurley wrote:
> > "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 take it to mean you should think twice before doing it -- especially
where you are actually changing (as opposed to adding/expanding)
functionality. If your change could break libraries or other code you
have written -- it is your responsibility. Put another way, consider
if the notational convience exceeds the cost.
Similarly not all core changes are created equal -- I cannot imaging
(outside of a joke) changing Fixnum#+ to be an alias for Fixnum#- but
there are times when adding a method to Array or more likely
Enumerable makes a lot of sense. You have the power to do either, but
it is your responsibility to write clear maintainable code.
> > 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.
But if that is the case, it is still likely the tests will fail (right
after I made the change) and back tracking to the cause is not too
hard. Tests are the safety net -- without them I would be afraid to
change most core classes as I would not know if it might break other
code, gems etc I was using. With tests if something breaks I know
right away and can back track to the cause much easier -- even if I
had not written the test for the exact functionality that changed.
> 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.
But it is this great features that allow me to test and use patches
against other peoples code without modifying the original source.
I don't think we really disagree, but since my original answer may
have been to glib, I felt compelled to explain myself.
Enjoy yourself, otherwise why bother
pth