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

left <[email protected]> Mon, 11 Dec 2006 22:09:05 +0100
Newsgroups gmane.comp.lang.eiffel.smalleiffel
Message-ID <[email protected]>
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.
>
> The whole system is just a bunch of unrelated cluster trees, which
> order is given by the ACE file (or implied by config if no ACE file is
> used). Note that the -verbose flag in very recent snapshots displays
> the whole system as it is computed using a tree display. There can be
> more than one tree.
>
> See the comments I added in a very recent snapshot, in
> ACE.find_class_text (around line 690).
>
> 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.
>
> I hope my explanations are clear. All comments are welcome.
>
> Best regards,


my comment:

don't you think it just looks like a miss of 
namespace/package/whateveryouwant feature to the language ? Explicit (in 
the code) is sometimes better. And what if people don't use Ace files? I 
know class names clash has always been an unsolved problem with SE (i 
posted about this some times ago and there was no solution), but i don't 
think you are choosing the most elegant way to solve it. Grabbing good 
ideas elsewhere is sometimes better that inventing a new wheel ;)


regards,

<- left