On 5/7/06, Pistos C. [email protected] 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 =)