From: Richard M K. <kr...@pr...> - 2008-08-01 14:15:45
|
"Nikodemus Siivola" writes: > On Fri, Aug 1, 2008 at 12:35 PM, Christophe Rhodes <cs...@ca...> 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)) (native-namestring pathname)) but why require the user to take the extra step? -- Richard |