26.01.14, 00:51, "Robert P. Goldman" rpgoldman@sift.info":
Faré wrote:
On Sat, Jan 25, 2014 at 7:58 AM, Anton Vodonosov avodonosov@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 wait...).
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.
thanks, r
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).
Best regards, - Anton