On Sun, 24 Oct 2010, Robert Goldman wrote:
On 10/22/10 Oct 22 -11:56 PM, Daniel Herring wrote:
On Fri, 22 Oct 2010, Faré wrote:
2- is depending on a suppressed component a bug, a nop, or something that forces the component to be un-suppressed?
If X depends on Y, and Y has been disabled, then X cannot load properly.
Was Y a requirement for X, or just something that should load earlier? If the former, then X should not be allowed to load. If the latter, then there's no issue.
If X is not allowed to load, under what circumstances should this cause the operation to fail?
Rather than ponder these ambiguities, maybe it would be better to let the user insert errors where they belong, possibly using IF clauses? Then ASDF could adopt the simple rule of proceeding unless told otherwise.
I'm reluctant to see us go down this path.
The primary advantage of having feature dependencies, over the #+ mechanism that CL already offers us, is that feature dependencies are declarative and enable introspection.
And error declarations do not prevent that.
If we let people write programs in feature dependencies, these advantages will go away.
Without those advantages, we might as well not complicate ASDF with feature dependencies; we can just let system definers continue to use reader conditionals....
So I'd suggest we define simple policies along the lines that Faré suggests.
That's find if people can agree on simple, flexible semantics. I made this suggestion because it seemed simple and flexible. C++ has taught me a dislike of coupling separate concepts together (e.g. struct vs class vs namespace).
- Daniel