1. If you're going to add :plist, you might as well un-deprecate :properties indeed. 2. The "idea" for extension is that the system class from :class would tell help inform what the system does, and, possibly, how to parse the defsystem. Of course, that only helps you if you define a new class, not if you have a new version of the "same" class that is defined in a new version of ASDF... unless somehow a new version of ASDF has several system classes, such as system3.5 vs system 3.4. 3. Maybe indeed ASDF would usefully include some form or initarg that ensures a recent-enough ASDF is available, early enough in the build to provide a good error message... but of course, you'd have to guard usage of this form or initarg with #+asdf3.4 since it isn't defined yet... so defining such a form now will only lead to pain reduction after at least 2 years. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Sex without love is an empty experience, but, as empty experiences go, it's one of the best. — Woody Allen On Thu, Apr 29, 2021 at 9:53 PM Eric Timmons <etimmons@mit.edu> wrote:
"Robert Goldman" <rpgoldman@sift.info> writes:
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.
How practical is this one actually? The initarg checking is done by reinitialize/make-instance. I just tested on SBCL and got an internal error (SB-PCL::INITARG-ERROR) that was then intercepted by ASDF and turned into the catch-all load-system-definition-error.
I don't think the spec specifies the actual error signaled on invalid initargs, so we'd have to figure out what each implementation's internal error is (and hope they all include enough information to determine which initargs were invalid).
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.
For the same reasons as above I'm not sure this one is practical either. We just have no way of knowing which initargs are valid or not.
I think the best we can do at the moment is a plist slot that stores all initargs, invalid or not. Then if the system writer really wants it to work on older ASDFs, they can add :allow-other-keys t to their system to disable the built-in initarg checking (completely at their own peril), but still have their extra metadata saved.
It's definitely worth considering for ASDF 4, separating all the "metadata" that can't affect build semantics into a :metadata initarg and being lax by default on what's included there.
-Eric