1 Sep 02:14
RESOLVE: and QUALIFIED:
From: Eduardo Cavazos <wayo.cavazos@...>
Subject: RESOLVE: and QUALIFIED:
Newsgroups: gmane.comp.lang.factor.general
Date: 2008-09-01 00:14:48 GMT
Subject: RESOLVE: and QUALIFIED:
Newsgroups: gmane.comp.lang.factor.general
Date: 2008-09-01 00:14:48 GMT
Slava wrote: > Let me again propose the feature where if you have a:foo and b:foo, then > USING: a b ; foo, you get a parse time error about ambiguity in the search > order. We currently have ways to address the problem. For one, there is no ambiguity because the USING: order determines which one is referred to. It's not exactly correct to call this an ambiguity problem. What happens if the user of 'a' and 'b' decides to deal with the problem using the tools provided by qualified. Will they be allowed to? Will they be forced to use RESOLVE: instead even if QUALIFIED: does the job? Perhaps your proposal should be viewed as two separate items. One: throw a parse time error if more than one used vocabulary exports the same name which is in turn used by the using vocabulary. Two: A 'RESOLVE:' form which can solve the above issue. This would be in addition to other tools which are available to fix the problem. Ed ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/(Continue reading)
Let's suppose that a vocabulary is changed which triggers the shadow
possibility error in many other vocabularies. OK, the owners of those
vocabularies go and add RESOLVE: forms to fix the problem. Then later the
owner of the original vocabulary decides that it had too much of an impact
and decides to undo the shadow; she puts the offending word in a private
namespace or renames it. Now you have a bunch of unnecessary RESOLVE: forms
laying around.
This is similar to the problem of unnecessary items in a USING: list.
Have you thought much about how to handle this? Is it too agressive to throw a
parse error if USING: or RESOLVE: refers to a superfluous items? It would
actually help me in cleaning up my USING: lists. 
RSS Feed