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