Or maybe not. I’ve heard extremely little about anyone actually using
any of the libraries that make block-scoped core changes possible.
Maybe there isn’t all that great a demand for orderly ways to do it.
Well d’oh. They’re rare, and they usually give unconventional behaviour to
existing code, I’d be very surprised if they were present in stable
prouction-code due to the risks involved.
I think we’re talking about two different things. I’m referring to
Ruby Behaviors, Import Module, and a third project whose name I can’t
remember but which does something similar: allow for temporary changes
to core classes.
That gives me somewhat of an uneasy feeling. How many core tampering
libraries does RubyGems requires that may make me rely on methods which
are not really in the core?
Heh, apparently, I had the standard modification of existing classes in mind,
without extra scoping libraries all the time. Happens. I blame the caffeine.
My segue from the first of those topics to the second may have been
unclear. I agree that changing core/standard classes, in code that is
going to be shared, is a bad idea. My first round of thinking through
this problem (expressed in ruby-talk:14556) led me to write Ruby
Behaviors, the main positive effect of which (since it’s not much more
than a proof-of-concept library) was to spark a discussion at RubyConf
2001 about selector namespaces… and hopefully that will bear fruit
in Ruby 2.x.