Re: [cclan-list] asdf and relative names

[F. <fa...@gm...>]

2008/9/4 Richard M Kreuter <kr...@pr...>:
> Fair enough.  As I said, I don't object to your way of doing things, but
> I think I can think of 3 ways to acheive the desired effect without your
> patch:
>
> (1) Use modules for subdirectories, unless you need files in one
>    directory depending on files in another
>
We tried that at ITA. In a large body of code that gets constantly
refactored by tens of hackers, where dependencies are not clear and
not manageable (see the XCVB whitepaper about it), this is just not
practicable.

> (2) Supply a :pathname argument to the component's initializer, and use
>    sharp-dot to parse the string as you desire, e.g.,
We've used that a-plenty at ITA. It's very painful, redundant, and
still not portable.

> (3) Subclass SOURCE-FILE with a class that accepts an initarg for a file
>    specification string which you can then parse your own way no later
>    than COMPONENT-RELATIVE-PATHNAME.
We've used that, too. It's painful, and only used in special cases,
when my patch removes the pain and makes the feature available to
everyone.

Why not just offer relative pathnames to all ASDF users at all times?
Once again, it is ALREADY true that ASDF proposes its own non-portable
layer for component naming, only said layer won't currently handle
relative paths for you, and #\/ is forbidden from portable ASD files.
The proposed extension is thus conservative. 100% gain, and I already
paid the pain of writing, and it's been used at ITA for over a year on
a big project, so can be considered reasonably field-tested.

The only issue I see is the common bane of all extensions: that when
people start relying on it, they will need to upgrade their ASDF.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The naturalistic fallacy: "if it's natural, it's good."
The anti-naturalistic fallacy: "if it's natural, it's bad."
The a-naturalistic fallacy: "nature has no relationship to good and bad."