[asdf-devel] Operation inheritance usage
divanov11 at gmail.com
Thu Mar 22 06:05:51 UTC 2012
Robert Goldman wrote on Wed, 21 Mar 2012 13:32:03 -0500 22:32:
RG>> Is possible that two actions on the same component and operation
RG>> type to be pushed into the plan? I mean two pairs (c . o1) and
RG>> (c . o2), where o1 and o2 are instances of the same class, maybe
RG>> with different slot values.
RG> I tried to do some operation specialization and found that actually
RG> it didn't work very well. The reason is in make-sub-operation ---
RG> it's very hard to get operations to propagate upstream in a way
RG> that might seem obvious: If you have a sub-type of LOAD-OP, you'd most
RG> likely want to get that sub-type on the dependencies, but this
RG> won't happen without a really substantial amount of effort
RG> rewriting depends-on, etc.
One approach could be making make-sub-operation generic though this sounds
like an overkill.
RG> Adding entirely new operations works fine, but I have not found a
RG> comfortable way to refine existing operations. AFAICT the easiest
RG> way to get that effect is to drop new properties onto existing
RG> operation types. those properties DO get passed into the
An object-oriented basis for handling operations is a bright idea. But it
makes many things too complicated and gives no answer to theoretical
problems like the above (are (c . o1) and (c . o2) the same action?). I
wonder if it provides much benefit in practice.
It seems that using keyword designators like :compile-op, :load-op and the
like and methods with the eql specializers would be enough to many
applications. And accompanying all the methods with an additional parameter
to pass operation properties (or make them accept key arguments). That is
the way some old defsystem libraries are doing.
Another question I have got is the relationship between ASDF and LispWorks
defsystem rules. LW definitions are quite obvious.
If any of dependee actions are already in the current plan (as a result of
other rules executing successfully, or as a result of default system
behavior), they trigger successful execution of this rule, i.e. the
operation on the target component.
The actions that need to be performed before the rule can execute
successfully. This is a list of operation-component descriptions that should
be planned before the action on the target component.
In my understanding, ASDF :in-order-to is equivalent to :caused-by, and
:do-first is equivalent :requires. Is this correct?
More information about the asdf-devel