Re: Order of cluster searching with ace file (recent snapshot)

On Tue, 2006-12-12 at 15:47 +0100, Cyril ADRIAN wrote:
> Hi DAmian,
> 
> On 12/12/06, Damian Dobroczyński <[email protected]> wrote:
> > How could I tell SE compiler that I want use *the* class X from a/b/c/d2
> > cluster in text of class Y instead of class X from a/b/c/d cluster?
> 
> If you have two classes with the same name at the same nesting depth,
> there is a problem. The compiler obviously cannot decide.

> But does this case happen in practice?

Yes, two classes of the same name, same program, even same cluster,
are definitely a perfectly normal thing. 

(1) A standard case is when you have different configurations.
Say you have alternative "implementation classes", e.g.
one set of classes uses facility supplier "this-kind"
and the other set uses supplier "that-kind":
  Imagine a vector of n discrete configuration variables,
like (DB-to-use, Simulation-mode, FPT-hardware, ...). 
Part of the choice can be abstracted away by using interface
classes (deferred), but how do you choose/test/load just one
implementation set at compile time or at run time?

One trick is to use directory links if supported, and load
classes from directory ./xyz -> ./this_conf, or from
./xyz -> ./that_conf. This trick cannot be used when the file
system or OS software doesn't support links. Another option
is to have make + system tools clean directories and copy
files of a configuration into a cluster directory. But why,
if we have Ace-like files, and the prospect of deterministic
class search algorithm?

In order to be able to switch and test easily, you need to be
able to point the compiler to the right class (but without
modifying class names in source all over the place,
obviously.). I'd even go so far and say that when there
is *no* programmer defined choice, *and* a homograph is found
at *any* level/depth, an error should be signalled!
Anything else would be very similar to DLL Hell (TM),
which IMO hinders reliable and productive development.

Indeed standard techniques of setting up a configuration use
directories and/or configuration files of some grammar.
Eiffel has Ace languages. I'd definitely like to be able
to say that cluster foo's classes A, B, and C are  to
be associated with "this_conf_dir/{a,b,c}.e" now, but later
with "that_conf_dir/{a,b,c}.e", using two configuration
files or two configurations of some kind
(inspect $CONFIGURATION when "this" then ... when "that" then ... ).

(2) Another case is when my programs use two unrelated clusters
and each of them has a "support" class, or "utilities" class
or some such of the same name. This is quite legitimate. 
Obviously they may live at the same nesting depth in different
directories. There is no way of preferring one class over the
other because both are needed. To me, requiring user
intervention in the Ace file seems a good choice. OTOH, I believe
a preference system is not viable here as a program needs
the services of both classes. Directly or indirectly.


Georg