[asdf-devel] The issue at hand
avodonosov at yandex.ru
Sat Jan 25 22:30:38 UTC 2014
26.01.14, 00:51, "Robert P. Goldman" <rpgoldman at sift.info>":
> 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
>>> as they do now: DOWNWARD-PERATION, SELFWARD-OPERATION, etc.
>>> 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.
I think this may be done without too radical changes.
I suppose the operation behaviour is represented by some generic functions
(probably returning the list of subcumponents to process by the operation,
when invoked on a component). By overriding these functions, a subclass
may tune its behaviour, no matter what superclasses it has. BTW, I am curious
what exactly generic functions
Each direct subclass of OPERATION should have overriden all necessary methods to behave
according to the subclass purpose (DOWNWARD-OPERATION, SELFWARD-OPERATION, ...)
This may be achieved introduction of an intermedate, unexporded, class between
OPERATION and DOWNWARD-OPERATION, SELFWARD-OPERATION, ...
It may be called NO-OPERATION, for example. This class overrides all the
generic functions in the operation behaviour protocol to work equally to the current OPERATION.
In this case, DOWNWARD-OPERATION and siblings change inheritance from OPERATION to NO-OPERATION;
rest of their code remain unchanged.
Below this level all the inheritance works exactly as now.
What remains it to implemente the old behavious in OPERATION without inheritence
from DOWNWARD-OPERATION and siblings. I don't know ASDF code, maybe some
helper functions need to factored out from DOWNWARD-OPERATION and simblings implementation,
to be reused in OPERATION, probably something will be duplicated, or maybe
some ASDF mechanizm will help (I remember I saw in some .asd file function
in-order-to mentioned; function named like that may probably be helpful).
More information about the asdf-devel