On 5/7/06, Pistos Christou <jesusrubsyou.5.pistos / geoshell.com> wrote:
> Right, so is this the sole problem?  People coding app X assuming
> CoreClass Y behaves a certain way, and then seeing that importing lib Z
> causes borkage in X (due to a change of Y)?

Yes, I think that's probably the biggest problem.  The other main
issue is the one you pointed out in the human/martian example.  I
believe that messing up the library is a worse situation, because the
library isn't in as good of a position as your code in terms of
knowing when things have been altered.  In your client code, you are
explicitly doing a require, so hypothetically you are aware of the
consequences of importing the second library.

> Is it ever safe to assume that Y#is_x? is so obscure or domain-specific
> that nobody would ever use it outside one's own application, and hence
> it is okay to extend the core class with?

I agree with you that you would probably be safe in 99.8% of cases,
but sometimes you are better off safe than sorry.  Ruby is flexible
enough to let you go either way, and that's a good thing.  If you are
confident go for it and modify the class; if not code more
defensively.

> I'm in the process of thinking it through, hoping to get some thoughts
> from others.  I don't know for sure yet either way, whether it's good or
> bad.  If it's bad, I want to stop doing it.  If it's good, then I can
> feel less trepidation whenever I do do it.

When it comes down to it, you probably need to evaluate the decision
on a case by case basis.  On a short script I might go ahead and open
String back up, but in a larger application, I'd tend to be more
careful.

Perhaps another thing to consider is on a more logical level.  If the
method is not something that *any string* should be able to do, you've
probably put it into the wrong class.

Good luck either way you decide, and write lots of tests =)



--
Lou