Kristoffer Lawson schrieb:
Usually one works on a development version where all debug options and checks are turned on — you want to capture anything as soon as it happens. Then you turn them off for a delivery version (if for no other reason than to enhance performance).
no question, useful scenario. allthough, the notion of "everything" might be different in various cases. sometimes, really all objects are the scope of the checking, sometimes "user code", file scope, namespace scope, class scope or object scope. the lowest common denominator is the object. this looks to me as a good thing for a library function (package).
As with most functionality in XOTcl there is the 'inst' methods, which are often given to classes, and then the direct ones for objects. Thus it would seem logical to have that for asserts as well.
i am not so convinced about the "inst" variant. "inst" means, provide some resources for the instances of a class, usually the instances can decide to override/extend it. what happens, if the inst rule turns checking on/off but the instance turns if off/on, or sets different values, etc. this is different to what we have discussed so far, and not terribly important imho. A package makes more sense, which makes it easy to extend/modify the behavior.
Neither of our solutions are really the kind of thing basic coders would come up with.
providing a few general idioms makes the developer more productive on the long range than one more built-in.
cheers -gustaf
/ http://www.fishpool.com/~setok/