On 5/7/06, Pistos Christou <jesusrubsyou.5.pistos / geoshell.com> wrote:
> The other responses which gave "why don't you do X instead" look like a
> parent giving into the whinings of a spoiled brat, and I thought the
> philosophy of Ruby was that computers and software are our slaves, not
> the other way around.

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.

Computers and software are not slaves.  They are tools, and you need
to handle them with care.  I don't think that ability to reopen a
class should be taken away, but at the same time I do think you need
to be careful and *think* about what you are doing.  If you want to be
all gung-ho with the nail gun, that's fine, but you better know your
stuff.

> Are we phobic to change core classes because one file/app/library might
> expect the method to behave one way, while another would expect
> something else?
>
> --- human.rb
> class String
>   def tasty_food?
>     /pizza|sushi|curry|steak/ === self
>   end
> end
> --- EOF
> --- martian.rb
> class String
>   def tasty_food?
>     /roaches|slime mold|pond scum|worms/ === self
>   end
> end
> --- EOF
> --- intergalactic-dinner-party.rb
> require 'human'
> require 'martian'
> foods = load_food_array
> foods.each do |food|
>     serve food if food.tasty_food?
> end
> --- EOF

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.

> 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.


--
Lou