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@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@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