ASDF components are brittle for backwards compatibility

[Robert Goldman]

On 29 Apr 2021, at 13:38, Marco Antoniotti wrote:

> Robert, it was you who suggested to use it if I remember correctly.
>
> How would it be different from what you just proposed?

My suggestion to use the `:properties` slot was not a good one.  Looking 
at the code, this slot is clearly marked as being only for ASDF 2 
backwards compatibility (it's hard for me to believe that this is even 
an issue any more).

Hence my suggestion of a new name, `:plist` for use instead.

I should probably deprecate the `:properties` slot, since I don't know 
what it was originally used for...  At least generate a warning.
>
> 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/6f1ccc5d/attachment.html>