Lou Scoras wrote:
> Honestly, that's a little childish, don't you think?  You supposedly
> wanted opinions on the matter, and you got exactly what you asked for.
>  I'm not telling you how to do things, I'm simply offering
> suggestions.

If there are sensible restrictions that exist with good reason, I am 
willing to "play inside the fenced area".  I just want to make sure the 
fences have good reason to be there, to be the size and shape that they 
are.

> Sure, that's bad enough, but that's not the real problem.  The BIG
> problem is not that it will mess up your client code but that it has
> the potential to muck things up in the library.  If you have more code
> in human.rb that depends on the definition of tasty_food? it's all
> going to blow up the minute you import martian.

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)?

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?

--- lemming-army-application.rb
class String
    def suitable_name_for_lemming_drill_sergeant?
        # ...
    end
end
--- EOF

>> So far, I don't feel convinced that it's a bad idea to create
>> String#vogon?.
> If you've thought it through, and you're comfortable with the risks it
> entails, then by all means go for it.  I just hope it doesn't come
> back to bite you later.

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.

Pistos

-- 
Posted via http://www.ruby-forum.com/.