[asdf-devel] patch system-source-file

Robert Goldman rpgoldman at sift.info
Fri Sep 25 20:04:50 UTC 2009


Tobias C. Rittweiler wrote:
> Robert Goldman writes (2009-Jul-09):
> 
> (Replying to an older posting,)
> 
>> I'd rather have us handle slot-unbound on those optional parts of the
>> system instead of stuffing a bunch of NILs in there.
> 
> Well, if you do not initialize slots with NIL, how can people know when
> it's safe to call an accessor?
> 
> Checking SLOT-BOUNDP would mean that users have to know about internal
> implementation issues: the slot names. 
> 
> In ASDF, it's especially icky because slots tend to have different names
> than accessors, so you really have to look into the source.
> 

I think we agreed that, in almost all cases, anyway, putting NIL in as
the default value would be OK.  There were a couple of cases where the
null string might be better (so we don't need (OR NULL STRING) types),
but I /believe/ that was it.

I think we concluded (IIRC, largely with James Anderson doing the
thinking) that there were few or no cases where SLOT-UNBOUND was necessary.

I was initially mentioning a concern about whether there might be cases
where SLOT-UNBOUND was appropriate.  IMO, slots should be left unbound
when it's a mistake not to initialize them.  I was speaking from a
concern that was born dealing with code where people would, as a matter
of routine, add ":initform NIL" to every slot definition.  That can fail
very badly when a slot needed to be actively set.  As I said, IIRC, we
decided that there were very few cases where this was the case (e.g., I
think it's actually an error for a component to be unnamed, but I don't
think that can ever happen).

There was some residual discussion about whether the meta-data (e.g.,
author, license, etc.) should have "" or NIL as the default initform.
This boils down to an aesthetic preference for whether :type (OR STRING
NULL) is worse than having to test with (equalp <attribute> "") [as
opposed to (null <attribute>)].  Both seem somewhat ugly.  I bet if
anyone took the trouble to make a patch, one way or another, that would
close the discussion.

Cheers,
r




More information about the asdf-devel mailing list