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



.

Relevant Pages

  • Re: implementing roles in OOP......
    ... > differently based on some context. ... but in this context Composite seems a misnomer - can I call it ... But yes dispatching is the encapsulation of this decision (and ... but I want a 'execution' of a network to be completely decoupled ...
    (comp.object)
  • Re: Flattening lists
    ... flatten generic iterables or only lists). ... this context, since I would say 99.9% of times one wants to treat them ... as atomic objects, so no need to special case. ... Dispatching ...
    (comp.lang.python)
  • Re: procedural vs object oriented
    ... The uncertainty of a dispatching call is one of the context, ... dispatching works or what potential targets do. ... case statement over all possibly redefined primitives. ... But if you consider that each called primitive may in turn redispatch ...
    (comp.lang.ada)
  • Re: procedural vs object oriented
    ... The uncertainty of a dispatching call is one of the context, ... dispatching works or what potential targets do. ... you can assume that every dispatching call is equivalent to a case statement over all possibly redefined primitives. ...
    (comp.lang.ada)
  • IE context menu extension in Win CE
    ... Its purpose is to extend the context menu in Pocket Internet ... It says that when DelayLoad = 0, ... what I am trying to do is I am trying to develop a Context ...
    (microsoft.public.windowsce.embedded)
Loading