[asdf-devel] patch for component-relative-pathname

Robert Goldman rpgoldman at sift.info
Mon Feb 22 00:41:24 UTC 2010


On 2/21/10 Feb 21 -6:35 PM, james anderson wrote:
> a question:
> 

>> On 2/19/10 Feb 19 -2:19 PM, Faré wrote:
>>>> 2.  SPLIT-PATH-STRING --- this is the one I think might need a  
>>>> ticket.
>>>> I confess I'm bamboozled by this one.  It's called on (component- 
>>>> name
>>>> component), not on a pathname.  Can you explain why the COMPONENT- 
>>>> NAME
>>>> would end up being a string that looks like a pathname?
>>>>
>>>> This SPLIT-PATH-STRING stuff looks like a relatively recent gwking
>>>> addition (if I understand the output of git blame correctly).  I  
>>>> don't
>>>> see what use case it was introduced for.  Anyone else have a  
>>>> clue?  I
>>>> see this docstring for component-name:
>>>>
>>> gwking might have done the checkin, but I am the one who wrote the  
>>> code at ITA,
>>> where we wanted to be able to use "foo/bar" as the name of a  
>>> component,
>>> instead of having all those ugly :pathname #.(make-pathname ...)
>>> ALL OVER THE DAMN PLACE for hundreds of components.
>>>
>>>> "Component name: designator for a string composed of portable  
>>>> pathname
>>>> characters"
>>>>
>>>> but I have never seen at component-name that was anything other  
>>>> than a
>>>> simple name, never something with directory separators.  Is this  
>>>> ever
>>>> used in the wild?  Or was this something that was added in an  
>>>> excess of
>>>> enthusiasm and that should just be killed (like the undocumented
>>>> tripartite FEATURE form)?
>>>>
>>> Yes, we use it a lot at ITA, and ASDF-DEPENDENCY-GROVEL
>>> and XCVB's ASDF front-end and backend use it, too.
>>>
>>> This change is 100% backwards compatible, since the behavior  
>>> before then was
>>> "undefined" when the #\/ character appeared in a name.
>>> Now it's defined and portable.
>>

> 
> why is this better than to leave names atomic and provide a standard  
> syntax to parse component relative (sic) pathnames?

Note that my whole last email is a red herring wrt this question.  My
last email assumes that Fare's change stays in, and I'm trying to write
it up in the documentation.

I.e., "let's you and him fight."  I am bowing out of this discussion.

best,
r




More information about the asdf-devel mailing list