<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 29 Apr 2021, at 13:38, Marco Antoniotti wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Robert, it was you who suggested to use it if I remember correctly.<br>
<br>
How would it be different from what you just proposed?</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">My suggestion to use the <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">:properties</code> 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).</p>
<p dir="auto">Hence my suggestion of a new name, <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">:plist</code> for use instead.</p>
<p dir="auto">I should probably deprecate the <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">:properties</code> slot, since I don't know what it was originally used for... At least generate a warning.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Marco<br>
<br>
<br>
On Thu, Apr 29, 2021 at 8:07 PM Robert Goldman <rpgoldman@sift.info> wrote:<br>
</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">That slot *is* there, but it is specifically noted as being for ASDF 2<br>
compatibility only, and not to be used. So you are using this at your own<br>
risk.<br>
<br>
Having a :plist slot might be a good addition, as well (i.e., both of my<br>
2 proposed solutions) as something lighter weight than my second<br>
alternative which is aimed at gracefully being able to extend ASDF's<br>
canonical metadata properties.<br>
<br>
On 29 Apr 2021, at 13:00, Marco Antoniotti wrote:<br>
<br>
Hi Robert<br>
<br>
Isn't the :properties slot already there? I just used it (a month ago)<br>
to add an ASDF DOCUMENT op to HELambdaP. Worked like a charm once I got<br>
the hang of it and it seals the general ASDF machinery from random stuff.<br>
<br>
Marco<br>
<br>
<br>
On Thu, Apr 29, 2021 at 6:13 PM Robert Goldman <rpgoldman@sift.info><br>
wrote:<br>
</p>
<blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><p dir="auto">ASDF checks to make sure all of the initargs are defined when parsing a<br>
defsystem. This is good for catching errors, but is terrible for<br>
extensibility. This means that any attempt to add additional metadata will<br>
be backwards incompatible.<br>
<br>
I can think of two ways to fix this:<br>
<br>
1.<br>
<br>
Add a "garbage can" slot to component that will be filled with a<br>
property list, and allow programmers to do whatever they want here. This<br>
doesn't seem great to me.<br>
2.<br>
<br>
Add a new defsystem parsing error class that is<br>
unknown-component-property, raise it when an unknown property is<br>
encountered and allow the user to continue, discarding the initarg and<br>
accompanying value.<br>
<br>
The second alternative is what I favor. It isn't great, because it will<br>
only maintain extensibility going forward, but I think it's the best we can<br>
do.<br>
<br>
I suppose that we could also add an initarg to tell ASDF to continue such<br>
errors silently. I'd be inclined to suggest that this take an ASDF version<br>
expression as value, so that the error is quietly ignored only by ASDF<br>
versions below that. This means that the property will start to be checked<br>
when it has become authoritative.<br>
<br>
Note that for one's own system and component subclasses, the set of<br>
initargs can be extended without any monkeying around.<br>
</p>
</blockquote><p dir="auto">--<br>
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01<br>
DISCo, Università Milano Bicocca U14 2043 <a href="http://dcb.disco.unimib.it" style="color:#999">http://dcb.disco.unimib.it</a><br>
Viale Sarca 336<br>
<a href="http://cdac2021.lakecomoschool.org" style="color:#999">http://cdac2021.lakecomoschool.org</a><br>
I-20126 Milan (MI) ITALY<br>
<br>
</p>
</blockquote><p dir="auto">-- <br>
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01<br>
DISCo, Università Milano Bicocca U14 2043 <a href="http://dcb.disco.unimib.it" style="color:#777">http://dcb.disco.unimib.it</a><br>
Viale Sarca 336<br>
<a href="http://cdac2021.lakecomoschool.org" style="color:#777">http://cdac2021.lakecomoschool.org</a><br>
I-20126 Milan (MI) ITALY</p>
</blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>