No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Asserts off/on
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 16 Jul 2006 13:53:42 +0200
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/
>
Date: Sun, 16 Jul 2006 13:53:42 +0200
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/
>