ASDF components are brittle for backwards compatibility

Marco Antoniotti marco.antoniotti at unimib.it
Thu Apr 29 18:38:53 UTC 2021


Robert, it was you who suggested to use it if I remember correctly.

How would it be different from what you just proposed?

Marco


On Thu, Apr 29, 2021 at 8:07 PM Robert Goldman <rpgoldman at sift.info> wrote:

> That slot *is* there, but it is specifically noted as being for ASDF 2
> compatibility only, and not to be used. So you are using this at your own
> risk.
>
> Having a :plist slot might be a good addition, as well (i.e., both of my
> 2 proposed solutions) as something lighter weight than my second
> alternative which is aimed at gracefully being able to extend ASDF's
> canonical metadata properties.
>
> On 29 Apr 2021, at 13:00, Marco Antoniotti wrote:
>
> Hi Robert
>
> Isn't the :properties slot already there?  I just used it (a month ago)
> to add an ASDF DOCUMENT op to HELambdaP.  Worked like a charm once I got
> the hang of it and it seals the general ASDF machinery from random stuff.
>
> Marco
>
>
> On Thu, Apr 29, 2021 at 6:13 PM Robert Goldman <rpgoldman at sift.info>
> wrote:
>
>> ASDF checks to make sure all of the initargs are defined when parsing a
>> defsystem. This is good for catching errors, but is terrible for
>> extensibility. This means that any attempt to add additional metadata will
>> be backwards incompatible.
>>
>> I can think of two ways to fix this:
>>
>>    1.
>>
>>    Add a "garbage can" slot to component that will be filled with a
>>    property list, and allow programmers to do whatever they want here. This
>>    doesn't seem great to me.
>>    2.
>>
>>    Add a new defsystem parsing error class that is
>>    unknown-component-property, raise it when an unknown property is
>>    encountered and allow the user to continue, discarding the initarg and
>>    accompanying value.
>>
>> The second alternative is what I favor. It isn't great, because it will
>> only maintain extensibility going forward, but I think it's the best we can
>> do.
>>
>> I suppose that we could also add an initarg to tell ASDF to continue such
>> errors silently. I'd be inclined to suggest that this take an ASDF version
>> expression as value, so that the error is quietly ignored only by ASDF
>> versions below that. This means that the property will start to be checked
>> when it has become authoritative.
>>
>> Note that for one's own system and component subclasses, the set of
>> initargs can be extended without any monkeying around.
>>
>
>
> --
> Marco Antoniotti, Associate Professor         tel. +39 - 02 64 48 79 01
> DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it
> Viale Sarca 336
> http://cdac2021.lakecomoschool.org
> I-20126 Milan (MI) ITALY
>
>

-- 
Marco Antoniotti, Associate Professor         tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it
Viale Sarca 336
http://cdac2021.lakecomoschool.org
I-20126 Milan (MI) ITALY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20210429/6b0dace0/attachment-0001.html>


More information about the asdf-devel mailing list