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