I have a note from you requesting that I mark SOURCE-FILE-TYPE as deprecated in code and documentation.
I'm not sure I fully understand.
The code in component.lisp still uses this, and it's not obvious how to remove it (nor what it means that it can return :DIRECTORY).
I *believe* that what you mean is that SOURCE-FILE-TYPE will stay, but that outsiders should no longer make methods on it: instead they should use the :FILE-TYPE slot on FILE-COMPONENT. But maybe not; see my point 3 below.
Some follow up:
1. This comment: " ;; SOURCE-FILE-TYPE below is strictly for backward-compatibility with ASDF1. ;; We ought to be able to extract this from the component alone with COMPONENT-TYPE.
That's out of date, right? Should refer to extract this from FILE-COMPONENTs along with FILE-TYPE, correct?
2. Why is FILE-TYPE an ACCESSOR instead of a READER? Should anyone be setting this, except as an INITARG?
3. What is the return type of SOURCE-FILE-TYPE, and in particular why does it not return an error when applied to a PARENT-COMPONENT? I think it's because it's not being used only as a FILE type, but is being used as a TYPE argument for ASDF's pathname functions, which have a more expansive notion of :type. I suppose maybe this means that SOURCE-FILE-type is a misnomer, and that's one of the reasons it should die.
I'm working my way through the ASDF manual, end-to-end. I will probably commit a marked up PDF to the repo pretty soon, so anyone who is interested can see where I'm going.
Thanks, r
On Sat, Mar 22, 2014 at 5:25 PM, Robert P. Goldman rpgoldman@sift.info wrote:
I have a note from you requesting that I mark SOURCE-FILE-TYPE as deprecated in code and documentation.
I'm not sure I fully understand.
The code in component.lisp still uses this, and it's not obvious how to remove it (nor what it means that it can return :DIRECTORY).
I *believe* that what you mean is that SOURCE-FILE-TYPE will stay, but that outsiders should no longer make methods on it: instead they should use the :FILE-TYPE slot on FILE-COMPONENT. But maybe not; see my point 3 below.
Yes, that's what I meant: the functionality remains for backward compatibility until all clients have been upgraded for months/years, but no one should define specialized methods on it anymore in new code, and the functionality will go away eventually.
Some follow up:
- This comment: "
;; SOURCE-FILE-TYPE below is strictly for backward-compatibility with ASDF1. ;; We ought to be able to extract this from the component alone with COMPONENT-TYPE.
That's out of date, right? Should refer to extract this from FILE-COMPONENTs along with FILE-TYPE, correct?
Yes.
- Why is FILE-TYPE an ACCESSOR instead of a READER? Should anyone be
setting this, except as an INITARG?
Reader is probably what it should be indeed. I don't know why I made it accessor.
- What is the return type of SOURCE-FILE-TYPE, and in particular why
does it not return an error when applied to a PARENT-COMPONENT? I think it's because it's not being used only as a FILE type, but is being used as a TYPE argument for ASDF's pathname functions, which have a more expansive notion of :type. I suppose maybe this means that SOURCE-FILE-type is a misnomer, and that's one of the reasons it should die.
I suppose the return type is (or string null (eql :directory)); yes, it's a misnomer, a misdesign, and it should die.
I'm working my way through the ASDF manual, end-to-end. I will probably commit a marked up PDF to the repo pretty soon, so anyone who is interested can see where I'm going.
Oops, I just made a few small changes to the manual. I hope they don't conflict.
PS: I also removed old merged branches from the repository, and created new ones. I invite you to merge in the renamed-bundle-op branch in which I rename bundle-operation as promised, and also the build-op branch that implements the strings as operation designator as well as renamed the build-system function to build (but I think the consensus is to further rename it to make). The standard-syntax branch is not ready and contains previous experiments for syntax control, that I hope we can complete and merge after the current release.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The weak terrorist who predictably loses, causing death for those he claims to defend is infinitely more evil than the strong one who wins.