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