Re: [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

prefer the latter, even at the expense of :type (or null string), so

discussing the tradeoff b/w "" and NIL as defaults. I'd be inclined to that an unsupplied value is readily distinguishable from an empty value.

Here's the system-source-file patch.

system-source-file.diff
Description: Binary data

The argument for slot-unbound is that it makes an error when you think

an initarg so that the value quietly vanishes.  Then I'd rather the

don't expect.

you have set a slot, but you haven't. For example, let's say I misspell system hurl an error instead of quietly going off and doing something I

I'd rather have us handle slot-unbound on those optional parts of the

system instead of stuffing a bunch of NILs in there.

ASDF to handle the condition, or having the caller handle/avoid the
condition?

When you say "us", do you mean implementing the accessors explicitly in

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

be looking into these things?  I suppose possibly so...

Is this really an issue? Would someone outside the ASDF package really

 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.

        (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.

You know, I considered this, but quickly dismissed it as too verbose. However, while I'd still prefer optional values to not signal slot-unbound, but I understand the tradeoff with catching errors in initforms, etc.

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
asdf-devel mailing list
asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel