[Asdf-devel] :AROUND methods

[Robert P. Goldman]

Faré wrote:
> But we don't invite programmers to redefine methods for existing classes,
> or at their own risk.
> 
> Why would these particular functions be special and require that
> there be a blank slate for :around methods?

I guess what seems funny about OUTPUT-FILES is that the main methods
have a return type that is *different* from the return type of the
generic function.

The main method should return two values:

1. A set of pathnames
2. A boolean that indicates whether the :AROUND method should translate
the pathnames.

Then the :AROUND method translates this so that only a single value -- a
set of possibly-translated pathnames -- is returned.

This strikes me as odd:  what would you describe the signature of
OUTPUT-FILES as being?

So neatness might argue that there be a POSSIBLY-TRANSLATED-OUTPUT-FILES
(with a better name, of course), and an OUTPUT-FILES (behaving as now),
with the former calling the latter, and each having a simpler signature.

That said, I don't see the need to break code for neatness.

As for "why these particular functions?" it's because (a) they are
exported and (b) we have invited programmers to define new methods for
them.  Doing (b) correctly arguably requires more understanding if you
have to know that there are existing :AROUND methods whose behavior must
be preserved.  If the :AROUND method was refactored to the previously
proposed P-T-O-F, the extending programmer's job would be simpler.  That
said, the existing contract for methods is simple enough that I'm not
going to worry about it.

I'm going to drop this into my email archive as "interesting, but
unimportant." I can return to it someday when tidying up unbroken code
is the only thing I worry about, i.e., never.

As for "actual extension points," I have occasionally added new methods
for these generic functions, but only simple ones. The only case I can
think of that might be a problem with the existing contract would be one
where there are multiple output-files, but only some of them are to be
translated.

To date, I have never written an extension that had > 1 output-file,
much less one that sent them to different places, so this is only a
hypothetical.  Perhaps an operation that built some data structure and
an index.... But I can't see why those would go in different directories.

Thanks for the explanation,
r