[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