ASDF components are brittle for backwards compatibility

[Faré]

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 at mit.edu> wrote:
>
> "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
>