[asdf-devel] The issue at hand

Robert P. Goldman rpgoldman at sift.info
Sat Jan 25 20:51:09 UTC 2014

Faré wrote:
> On Sat, Jan 25, 2014 at 7:58 AM, Anton Vodonosov <avodonosov at yandex.ru> wrote:
>> Theoretically, OPERATION may be the root class and keep the old semantics
>> (downward + selfward + other). And subclasses override this semantics
>> This may lead to some code duplication in ASDF.
> This sounds like a great transition plan indeed.
> Then we could have a warning for now, that would be transformed in an
> error in a year,
> and migrate to this new setup that detects wrongful combinations,
> without forcefully breaking things in the meantime.
> Robert, also, in the manual you should advertise #+asdf3.1
> non-propagating-operation, or something, because it won't exist
> earlier, and we probably want code to keep running with asdf 3.0 until
> every implementation has upgraded to 3.1.

OK, will do.  I will try to get all of the new operations written up,
but I don't believe I will have time until after the 31st (conference
deadlines, and end of contract dates mean that the ASDF manual has to

I do not yet the proposal.  How can OPERATION keep the old semantics and
still be the root?  There are 11 direct subclasses of OPERATION now, and
some fan out from there (e.g., a fair sized subgraph under BUNDLE-OP).
How is the overriding to be managed?

Currently, unlike in the proposal ("subclasses override this semantics
as they do now"0, subclasses do not override the semantics, do they?  My
understanding was that the behavior of the new dependency-propagating
classes was strictly additive.  Is that not true?  To make this new
proposal work, as I understand it, we have to add *subtractive*, or
non-monotonic behavior inheritance.

Unless I'm missing something, it seems like this new proposal will be
much more complex than the current approach, which just involves two
checks, and no modifications to core ASDF code.

I'm happy to see an approach that would provide no breakage, but I'd
like to see a more detailed proposal before we proceed.


More information about the asdf-devel mailing list