I don't mean to discourage innovative thinking here, but for reference,
consider that the editor and/or separate source indexer can locate defXXX
forms, and record the location of (define-widget cool-widget ...) as
(:definition (:name cool-widget :type define-widget) :location (:file
"file.lisp" :l
Agreed. As I indicated later, throwing away useful information wasn't my
intent -- having a tight, well-defined contract was. T serves that purpose,
but other values may also serve it and add utility at the same time.
The WORST case, in my mind, is to return something useful, but leave the
contrac
Just to clarify my earlier stance: I agree -- if there's something
well-defined and more useful than T to return, return that. It's the
'null/non-null' contracts that are problematic.
The extra wiggle-room here offers no utility at all. It does allow for one
branch of an implementation to avoid a
Dan, my firm-but-not-rabid opinion on this has been formed from decades of
tracking down portability bugs, irreproducible bugs, etc.
Return 't'. Try to get the contract tightened up to specify t.
But so long as the contract is loose, in testing it can be useful to try to
inject defects by returni
Dan Weinreb wrote:
"At least one reason, and maybe the only reason,
is that the initial value is figured out in a way
that may depend on class precedence."
Well, another reason is that they're associated with the class, and can thus
be introspected as part of some protocol where you supply a class
