From: Jay Levitt <jay+news@...>
Date: 2007-10-09T13:10:07+09:00
Subject: The Open-Closed-from-a-certain-angle Principle

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?

-- 
Jay Levitt                |
Boston, MA                | My character doesn't like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm         | - Kristoffer