On 2/22/10 Feb 22 -10:02 AM, Faré wrote:
I am inclined to agree. I'd be happier if we could just say something like
(:file "foo" :relative-directory "bar")
instead of
(:file "bar/foo")
Why? You're just moving the complexity around, without simplifying the overall design. Moreover, the astute user is already familiar with /-separated paths (from URLs if not from his filesystem) and the second notation leverages this familiarity. Which comes very handy when files are shuffled around. Finally, we need to parse names if only to portably handle the :static-file "foo.lisp" case -- why can't we parse paths at the same time?
Least surprise: reuse familiarity with filesystem paths and/or URLs Conciseness: fewer slots that get out of sync Generality: share the same mechanism with :static-file "foo.lisp"
Counterargument:
Confusion/duplication: Compute the component-relative-pathname through some confusing combination of :pathname and :name. Abuse of the :name to provide pathname functionality.
Non-orthogonality: Compute the pathnames of modules and files differently (name not used to give
For that matter, both of these are probably unnecessary now that module dependencies work and we can do:
(:module "bar" :components ((:file "foo")))
Not always doable. Especially when dependencies change and suddenly subdirectories are no longer perfect units of dependency. Been there, done that.
You don't have to map modules one to one to files. E.g.
(:module "bar" :components ((:file "foo"))) (:module "bar1" :pathname "bar/" :components ((:file "bletch"))
Right?
I have a project here with over 1400 files, not counting libraries. That trick doesn't work.
So, question: Fare, do we really need the additional hair now that intra-system module dependencies work? Wouldn't it be possible for you to macrologize your names-as-pathnames extension and purge the hair from the core of ASDF?
The hair is in the notion of CL pathnames itself. Get rid of it. How do you think this feature can be modularized anyway?
I don't agree. I think the hair comes from putting pathname computation into two places: into the name and into the :pathname. I'd rather see all the pathname computation delegated to the :pathname argument.
I'd love to see all this extra code get purged....
I disagree. If you compare with the *broken* mess that was before and led to non-portable behavior in :static-file "foo.lisp", then no, this is not extra code. This is *less* code than was before, for more functionality, and in a more portable way.
The feature is now solved. It is a bug in the documentation if it says otherwise.
Actually, now that I think of it, for portability reasons, and to avoid all these ugly :pathname #.(make-pathname ...) any string argument to :pathname should be processed through component-name-to-pathname-components. You can still #p"..." if you want your system's non-portable parse-namestring, or #.(make-pathname ...) if you are crazy about it.
Currently, :pathname <string> is non-portable and thus USELESS.
I'd rather fix :pathname than add hair to name....
Cheers, r