[asdf-devel] patch system-source-file

[james anderson]

On 2009-07-14, at 19:35 , Robert Goldman wrote:

> james anderson wrote:
>>
>>> [...]
>>>>
>>>> 4. if one would like to see the code at the version which  
>>>> constitutes
>>>> the current approach to this issue, which revision should one pull?
>>>
>>> I don't have a good answer for this, sorry.
>>>
>>> I think that James clearly states the issues.  I propose we just  
>>> try to
>>> come to consensus on something like the following:
>>>
>>> 1.  We specify which of the system string initargs are actually  
>>> optional.
>>>
>>> then either
>>>
>>> 2a.  We specify these as being of type string and specify that  
>>> they take
>>> "" as a default.  Supplying NIL would be a type error.  For the  
>>> benefit
>>> of non-type-checking lisps, we could add :after methods on
>>> initialize-instance to reject non-string values.
>>>
>>> 2b.  We specify that the type is (or null string) because we want  
>>> to be
>>> able to distinguish unsupplied from explicitly empty.
>>>
>>>
>>> These both seem reasonable alternatives, as long as we state one  
>>> of them
>>> clearly.
>>>
>>> If someone will express a clear preference that isn't shouted  
>>> down, I'd
>>> be happy to provide help either documenting or coding up support.
>>
>> i propose, 2b iff some operator depends on the distinction.  
>> otherwise 2a.
>
> Here are the initargs from which we have to choose:
>
> :licence :license :maintainer :author :long-description :description
> :default-component-class :if-component-dep- 
> fails :components :properties
> :pathname :parent :do-first :in-order-to :name :version
>
> Of these, I believe our discussion pertains primarily to
>
> :license/:licence
> :maintainer
> :author
> :description and :long-description
> :version
>
> Are these all truly optional?  Personally, I wish that :version  
> wasn't,
> and/or that we enforced some standard on values supplied there, since
> it's easy to put in something that will cause version-satisfies to  
> choke.
>
> How about we confine our attention to all of these EXCEPT :version,
> which is worthy of a discussion of its own.
>
> These are all going to be used primarily by software which simply
> displays information about the systems, and all of that software  
> (unless
> there's a 'describe' method) is going to be external to ASDF proper,
> which means it's hard for me to answer James' "some operator  
> depends on
> the distinction" question.


none of author, description, long-description or maintainer are  
referenced in the asdf code (nb i'm still with 1.130)
i worry about the potential use-case, that some app would want to  
impute values from a module to its components.
this argues that NIL should be the default.

i don't know of the uses to which one puts license, but were it to  
matter, one could argue, that asdf should enforce canonicalized  
license keywords. i've no idea where to find such a thing, but there  
must be one "out there". this might require the addition of a  
"license-description" field (with a "" default).

version, on the other hand, is used internally. i have never used it.  
the predicate reads as if it requires a string to compare and  
interprets an unbound slot as a wildcard. that is not good. a  
distinguished value would be better. it reads as though improvements  
to the logic to supported internal wildcards and/or interval  
expressions in the version specification would not hurt its utility.

as to the others:
default-component-class : is cl-source-file
if-component-dep-fails : is :fail
components : are there any arguments against an empty module? if not  
this should default to NIL.
properties : is NIL.
pathname : the version i have reads as if this value is defaulted by  
the interface operator. if that is the intent, the class definition  
should  have an error form for the initform.
parent : is NIL
do-first : id NIL
in-order-to : is NIL


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20090714/a9516ad2/attachment.html>