From: mortee <mortee.lists@...>
Date: 2007-10-11T03:19:25+09:00
Subject: Re: The Open-Closed-from-a-certain-angle Principle

Michael Reinsch wrote:
> 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.

I think the name collision problem might best be solved on a file-based
approach. It should work something like how the method namespace
partitioned by modules works on a class-based approach.

I mean, any source file should be able to state a, let's say, "layer" (I
don't have a better term for now), which is simiar to a module. Any
methods this file adds to existing classes/modules would be associated
to that layer. (*)

Now, any file which makes use of the extra methods added by the file
mentioned above should explicitely state that it uses the named layer.
This property wouldn't be inherited by other files when they require
this one.

This way, any library/application could define its own private layer of
methods, which all of the source files of the given package could state
to use - thus defining and using its own utility methods (added to core
classes or ones of other libraries). Yet this wouldn't conflict with
other used packages' own private utility methods (because the layer
usage wouldn't be inherited from file to file).

Also, if an application wants to use those utility methods defined by
some library, it can do so, without disturbing other used libraries.

Does this make sense? Could it be implemented in a reasonable way?

mortee

(*) I propose using named layers instead of filenames themselves so that
multiple files could state the same layer - and this would also mean
they also use the layer they state. This way, every file of a given
package could state and use a single shared layer, in one step. This may
be simplified even further if the layer can be specified by the package
itself the file in question belongs to: then one would have to
explicitely use only other packages' layers, the current package's layer
would be included automatically.