On Tue, 09 Oct 2007 00:06:18 -0400, Jay Levitt wrote:

> Let me start off by saying that I'm SURE this is either a bad idea,
> impossible to implement, or both.  I just can't enumerate the reasons
> why, and I thought this would be a good group to shoot it down.
> 
> Since it's so easy to add new functionality to Ruby core classes (which
> are open for extension), many libraries do.  Rails adds all sorts of
> things in Active Support, and other frameworks and libs do similar
> things.  Gems does with Time::today, but is about not to, so that it
> doesn't step on anyone else's Time machines.
> 
> Yet adding, say, String#to_leetspeak is a much cleaner alternative than
> defining a global to_leetspeak(String) method.  The key is to stop the
> leetspeak from leaking into other modules.
> 
> What if class definitions were viewed through a magic prism, where only
> those classes looking from the right perspective saw the new extensions?
> Mind you, I have no idea how to partition the codespace in any sane
> manner - even from a design spec point-of-view.  Should ActiveRecord see
> Og's extensions?  Probably not; but ActionView and ActionPack might want
> to share.  And what happens if Og passes a Hash to ActiveRecord that
> happens to include an Og-provided Time#today in it?
> 
> I dunno.  On the surface it seems that there must be some nicer way to
> add better locality of reference to core extensions, but I can't imagine
> how it would be implemented, how it should work, or if it would even be
> a good idea.  Just some good old Sunday night musings.
> 
> Do other languages do anything like that?

Groovy does something like this with use(Category){ code... }. The only 
thing is that the added methods are visible to everything that the 
included code calls, whether you wrote it or not. So it's still not quite 
what you're asking for.

--Ken

-- 
Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/