From: Michael Reinsch <mr@...>
Date: 2007-10-10T13:01:54+09:00
Subject: Re: The Open-Closed-from-a-certain-angle Principle

Hello,

On Wed, 2007-10-10 at 05:05 +0900, Jay Levitt wrote:
> On Wed, 10 Oct 2007 01:53:43 +0900, mortee wrote:
> 
> > Having modules to partition name space is great - but since any feature
> > can extend any pre-existing class/module with its own methods, those are
> > in no way proected from name clashes within a given module/class.
> 
> Yeah, that's really the core of it - preventing namespace collisions, so
> that gems's Time::today doesn't conflict with, I dunno, facets's.

I also did some thinking about this matter (though not specifically for
ruby) from the angle of software evolution and outlined some ideas in a
paper for RAM-SE05 (http://mr.uue.org/me/pub/disentangledparts.pdf).
Though this paper describes a different approach to tackle the problem,
it made me think more about method dispatching and I now think that this
could probably be done by extending the dispatching mechanism. Why in
the dispatching mechanism?

Well, dispatching usually chooses a method based on the object's class.
Or on a more abstract level we could call the dispatching criteria the
"object's context" (in lack of a better name), as it is bound to the
object. So we can say: the usual dispatching as we know it is done on
the object's context.

The idea now would be to extend this and to also allow dispatching on
the other contexts, such as the caller's context. What is that "caller's
context"? Well, this needs to be defined per implementation probably,
but as the name suggests, this is something bound to the caller of a
method.

Don't think something like that is needed? Well, actually, ruby (and
most other OO languages) already take a very simple caller context into
account when a method is called, defined by "public", "protected" and
"private". C++ supports friends, which also defines a caller context.

But redefinition of methods is usually not allowed in existing
implementations for different contexts other than the object's context.

One big challenge is IMHO coming up with easy and natural ways to define
those caller contexts (and other contexts) within a language. But as
this email is already quite long, I'll stop here in the hope I could
seed some ideas. I already got some interesting new pointers through
this thread. Thanks to everybody participating!

-- 
Ubiquitous Business Technology, Inc    http://www.ubit.com/
Michael Reinsch                        Tel: +81-3-5804-0104