On Sat, Jun 7, 2014 at 4:02 PM, Robert P. Goldman rpgoldman@sift.info wrote:

I was wondering about the :AROUND methods for OUTPUT-FILES and INPUT-FILES, which are exported and which we invite programmers to provide methods for.

I don't think this is necessarily a big deal: we explain pretty carefully the contract for these functions (I need to check on the discussion in the manual). But we *could* add a wrapper function around OUTPUT-FILES (resp. INPUT-FILES) and put the :AROUND logic in that, and have ASDF internally call the wrapper function instead of OUTPUT-FILES (resp. INPUT-FILES).

Would this be a worthwhile clean-up?

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?

If any actual programmer comes up with a need for more extension points, *then* extension points can be provided.

In addition to the perform-with-restarts issue, the development of ASDF2 and ASDF3 already led to defining plenty of new extension points so that the various extensions used at ITA (most notably POIU and ASDF-DEPENDENCY-GROVEL) could be written without overriding ASDF internals. The advantage of letting actual clients drive the definition of extension points is that you then know that your extension points make sense and have at least one client that'll test the functionality.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Faré's Second Law of Dissent: I am Right, whence it follows that all who disagree with me are either (1) evil, (2) stupid or (3) crazy. (The alternatives are not mutually exclusive.) This universal law is valid for all values of "me", including "you".

On Sat, Jun 7, 2014 at 7:13 PM, Robert P. Goldman rpgoldman@sift.info wrote:

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?

Actually, the toplevel :AROUND method *does* return two values, and the second is always T (see action.lisp line 274 as of 3.1.2).

The return signature is: (values (list-of pathname-designator) &optional boolean)

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.

The problem with that approach is that OUTPUT-FILES is an interface both for providers and consumers. Many extensions expect to call OUTPUT-FILES, and many extensions expect to define methods on OUTPUT-FILES. It might be a design mistake that the same function name be used in these two cases, which doesn't leave much room to interpose functionality between the two. But if that's the case (of which I'm not convinced), then that's a mistake that was made in the original ASDF, and can't be fixed without massive backward incompatibility. Happily, the :AROUND method is a good enough solution to this issue, at least so far.

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.

You can't do that without breaking backward compatibility, or at least having a long and painful transition period. I'm not sure this is warranted, though you have an actual case for making such a change, the earlier you start the transition period the better.

I believe that it's OK to have to look at existing methods and not override them without reproducing functionality and sending a feature request for an extension point.

Also ((o operation) (c component)) vs ((o t) (c t)) usually leaves enough space for an :AROUND method already.

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.

The canonical term for that in jargon file is "in my copious free time".

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.

In these cases, you can explicitly call apply-output-translations on those outputs that need be translated but not the others, and return T as the second value.

Thanks for the explanation, r

Regards,

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Not all Law is created equal before Man. Some Law causes least conflict and least perverse incentives. By definition we call it Natural Law.