Dependency across systems

Bug #1294035 reported by Faré
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ASDF
New
Undecided
Unassigned

Bug Description

ASDF1 and ASDF2 did NOT allow a component to depend on anything but a direct sibling. ASDF3 will let you specify that, if you define a component-depends-on method that directly refer to them as objects rather than names.

Should we allow it? Some bundle operations will get it wrong, but maybe they deserve it.

Cheers,

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If you're a quiet, law-abiding citizen most of the time but occasionally cut
someone up and bury them in your backyard, you're a bad guy.
        — Paul Graham, "The Power of the Marginal"

Revision history for this message
Robert P. Goldman (rpgoldman) wrote :

What would be the means of prohibiting people from doing this? We could make COMPONENT-DEPENDS-ON be a function instead of a generic function, I suppose (that sounds hard), or not export it from ASDF/INTERFACE (this would not absolutely prevent specialization, but would warn people who do specialize that we reserve the right to break their code).

Is that what you have in mind?

Revision history for this message
Faré (fahree) wrote :

NB: I think the importance/difficulty ratio of this change makes it not a suitable candidate for the impending release, but nevertheless wanted a place to dump this idea. Let's table this discussion until after release. The issues that I think are release worthy are: A non-hidden default source tree https://bugs.launchpad.net/asdf/+bug/1293278 and Fix defsystem to accept strings as operation designators https://bugs.launchpad.net/asdf/+bug/1293292 — thanks.

I see several potential solutions:

(1) document that the user is on their own if a file A defines a dependency on a component B from another system. For instance, if A's system is forced-not. the traversal might not see B if even if its system is forced.

(2) enforce the restriction (or merely check it and warn?) by adding around method for load-op, compile-op and/or prepare-op, (or all operations, unless they belong to an authorized subclass, such as gather-op (?)) that check the results of component-depends-on: unless the operation is authorized, then every component nust be a string (resolved in the parent), or the component itself, or one of its children, or the parent of the component, or maybe component in the same system. Another exception is for system objects themselves: they may depend on other any operation with another system, as well as any operation with its children.

Revision history for this message
Faré (fahree) wrote :

required-components and after them bundle operations are other potential casualties of direct dependencies from a child component to (something in) another system.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.