From: Richard M Kreuter <kreuter@pr...> - 2008-08-01 14:15:45
"Nikodemus Siivola" writes:
> On Fri, Aug 1, 2008 at 12:35 PM, Christophe Rhodes <csr21@...> wrote:
> >>> * What would anybody think of having it implicitly translate a logical
> >>> pathname and return the native-namestring of the translated pathname?
> > I'm not sure. My thought process, I think, was that
> > NATIVE-NAMESTRING was for interfacing with the system, and that
> > probably any attempt to use logical pathnames with that was a
> > symptom of a mistake. I'd like to see reasoning for this permissive
> > change, rather than simply noting it's upward-compatible because it
> > was previously an error case.
> My reasoning:
> Logical pathnames are pathnames, not random object which may or may
> not have mappings to pathnames. All (ok, I didn't check, but IIRC) CL
> functions that accept normal pathnames accept logical pathnames as
> well, so having N-N be the exception would be... exceptional.
This is basically my opinion, too. ISTM that if one wants to use LPNs in
a program, as likely as not, you'll eventually want to call some
function that wants a filename in native syntax. It's not hard to wrap
NATIVE-NAMESTRING in something that does this:
(if (typep pathname 'logical-pathname)
(native-namestring (translate-logical-pathname pathname))
but why require the user to take the extra step?