On 5/4/06, Louis J Scoras <louis.j.scoras / gmail.com> wrote:
> I think the problem is in the expectations.  Why would you expect that
> two /executable runtime/ statements would not depend on the order in
> which they are executed?  Require is just another method.
>
> I have to agree with James on this one.  If I've written a library
> that plays nicely and then somebody comes along and pulls the rug out
> from under my feet, there's not much I can do about it.  My code isn't
> the one that is mucking things up.  Besides, if I was suitable
> paranoid I could check to make sure I'm not redefining a class and
> steping on anybody elses feet:
>
>     fail %q{I don't like what's going on here!} if
> Object.const_defined 'ProblemClass'
>
>     class ProblemClass
>         # ...
>     end
>
> If I throw caution to the wind and stick my nose in other modules
> buisness I deserve to get rapped.
>
>
>
> --
> Lou
>
>

I'm pretty sure the problem is that you *don't* get rapped for
sticking your nose in other modules.

If I write ProblemClass, then install a gem that defines it, or some
newbie on my team messes around with it, then *I'm* the one who gets
the nasty surprise.  Now there are some pretty simple solutions to
this - ensure you have good procedures in place to keep this from
happening, have a thorough test suite, etc - but the only thing that
David is suggesting is that there be a mechanism to keep these
modifications from happening.

I'm reading David's comments as, "Yeah there are ways to protect
against this, but why not just let the computer handle it?" 
Procedures don't always get followed, and really I see no reason why
my unit tests should break because somebody else was careless.  I
don't have a need for it, but David's opinion here seems entirely
reasonable to me.

Wouldn't it be a lot nicer to do

class DontTouchMe
  include Freezable
end

to ensure that nobody messes around with it?  Procedures can be
error-prone, cause let's face it, sometimes they just take a back seat
when you're in a crunch, and having your unit tests randomly blow up
is inconvenient, not to mention a waste of time when you have to
search for the culprit.

Pat