[asdf-devel] patch system-source-file

[Greg Pfeil]

On 12 Jul 2009, at 11:17, Robert Goldman wrote:

> Greg Pfeil wrote:
>> On 9 Jul 2009, at 13:08, Robert Goldman wrote:
>>
>>> Greg Pfeil wrote:
>>>> Here are a couple changes to ASDF that I made in the process of  
>>>> creating
>>>> an ASDF browser for CCL's IDE:
>>>>
>>>>  system-source-file now works for systems without their own .asd
>>>>  optional parts of systems (version, maintainer, etc.) don't leave
>>>> their slots unbound
>>
>>> The first of these looks good, but I'm less fond of the second  
>>> change.
>>> I've been bitten repeatedly by bugs caused by initforms that caused
>>> slots not explicitly set to have some value that hides a mistaken
>>> failure to fill the slot.
>>
>> Yeah, I should have sent these as separate patches. The first one is
>> more important, IMO, and the second is definitely debatable.
>
> How about sending that first patch while we work through the second
> issue.  Even if we add the initforms, seems like it's still worth
> discussing the tradeoff b/w "" and NIL as defaults.  I'd be inclined  
> to
> prefer the latter, even at the expense of :type (or null string), so
> that an unsupplied value is readily distinguishable from an empty  
> value.

Here's the system-source-file patch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: system-source-file.diff
Type: application/octet-stream
Size: 1246 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20090712/179294b5/attachment.obj>
-------------- next part --------------


> The argument for slot-unbound is that it makes an error when you think
> you have set a slot, but you haven't.  For example, let's say I  
> misspell
> an initarg so that the value quietly vanishes.  Then I'd rather the
> system hurl an error instead of quietly going off and doing  
> something I
> don't expect.
>>
>>> I'd rather have us handle slot-unbound on those optional parts of  
>>> the
>>> system instead of stuffing a bunch of NILs in there.
>>
>> When you say "us", do you mean implementing the accessors  
>> explicitly in
>> ASDF to handle the condition, or having the caller handle/avoid the
>> condition?
>
> The latter.
>>
>>> If one is expecting strings here one must still handle checking  
>>> for NIL,
>>> so having to check for slot-boundp doesn't seem that much more  
>>> onerous.
>>
>> Checking slot-boundp has a number of problems:
>>
>>  you have to export the slot names
>
> Is this really an issue?  Would someone outside the ASDF package  
> really
> be looking into these things?  I suppose possibly so...
>
>>  it breaks the accessor abstraction because the slot names don't  
>> match
>> the accessor names
>>    (when (slot-boundp foo 'asdf::description) (system-description  
>> foo))
>
> (handler-case ....
>  (slot-unbound () ...)
>
> avoids this problem, if you know that you want to quash unbound slots.

You know, I considered this, but quickly dismissed it as too verbose.  
However, while

	(handler-case (system-description foo) (slot-unbound () ""))

is worse than the

	(or (system-description foo) "")

that I wanted, it's still better than the

	(when (slot-boundp foo 'asdf::description) (system-description foo))

I was afraid of. I'm happy to use that pattern.

I'd still prefer optional values to not signal slot-unbound, but I  
understand the tradeoff with catching errors in initforms, etc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20090712/179294b5/attachment.sig>