ASDF components are brittle for backwards compatibility
Eric Timmons
etimmons at mit.edu
Fri Apr 30 01:52:49 UTC 2021
"Robert Goldman" <rpgoldman at 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
More information about the asdf-devel
mailing list