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 _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
