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