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

Cyril ADRIAN wrote:

> Hi Oliver,
>
> On 12/8/06, Oliver Elphick <[email protected]> wrote:
>
>> a class that was in both local and system (in different versions) was
>> chosen from system by compile and from local by finder.  Changing the
>> order of clusters changes the result from finder but compile always
>> chooses the system cluster.
>>
>> Do finder and compile use different search algorithms?
>
>
> Not exactly. To answer to your question, I have first to explain how
> class finding is working in the recent snapshots.
>
> The aim is to allow more than one class to have the same name in the
> system, while automatically resolve ambiguities without relying on
> user parametry. In fact, the basic idea is that a group of classes (a
> library, a framework, or an application) is self-consistent.
> Therefore, when a class uses another class, it "expects" it to be the
> one the author (of the classes bundle) thought of. There are two
> cases:
>
> - either the author wrote the class. In that case he really wants
> *that* class to be used, even if another class with the same name
> exists within the system
> - or the author uses a standard class, or a library class, and of
> course he should be able to do so.
>
> To implement that, SmartEiffel now uses a notion of "class distance".
> Class distance is just the reification of what I wrote above.
> SmartEiffel starts looking for a class starting from the cluster of
> its client. It goes down, then up; only then does it scan the whole
> system.
>
>
In some cluster C1, some file refers to the type T. The search system 
then find some file F1 for the type T.

In another cluster C2, some file refers to the type T (the same type 
name). I'm think the current compiler use the already known type. The 
good way should be to ask the class distance system which file F2 is to 
be used:
- if F1 = F2, everything is fine, use the already known type T,
- if F1 /= F2, it's a fatal error because there are 2 conflicing 
definitions for T, and using one file or the other could not depend on 
the class analysis order .

>
> Now, the problem with finder is that it does not know this notion of
> class distance. Distance from what?... So it just scans the whole
> system and picks the first class it meets with the good name.
>
> Does it mean that the new finding algorithm is bad? I don't think so.
> To me, we must add an option to finder to tell it where to start
> looking for the class. Another option would be for finder to display
> by default all the classes with a given name. It's still WIP.
>
May be, finder without starting point should give all files found for 
some name. Finder with starting point (directory or class file) is able 
to give the file used for some class name.

Best regards,

-- 
Philippe Ribet



                         The README file said
              "Requires Windows 95, NT 4.0, or better."
                    So... I installed it on Linux!