No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Asserts off/on
From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 16 Jul 2006 15:52:46 +0300
On 16 Jul 2006, at 14:53, Gustaf Neumann wrote:
> 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).
Personally I think the most common and logical ones would probably be
"everything", "these classes" and "this object".
>> 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.
I think that extending would still be perfectly fine. I mean,
basically what would happen would be that all instances would have
certain checks on, by default. This could then be changed on a per-
object basis.
>>
>> 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.
Well, in theory that could be said about the whole assertion system,
which could be done with filters and similar. Perhaps not even a bad
idea. Some things are useful for convenience and perhaps even
performance. The balance needs to be good, and I think if a feature
is in there, it should exist in completeness.
That's just my perspective as a developer but obviously you are the
designers behind the extension, so it is your call which features you
feel are important and which not.
/ http://www.fishpool.com/~setok/
Date: Sun, 16 Jul 2006 15:52:46 +0300
On 16 Jul 2006, at 14:53, Gustaf Neumann wrote:
> 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).
Personally I think the most common and logical ones would probably be
"everything", "these classes" and "this object".
>> 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.
I think that extending would still be perfectly fine. I mean,
basically what would happen would be that all instances would have
certain checks on, by default. This could then be changed on a per-
object basis.
>>
>> 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.
Well, in theory that could be said about the whole assertion system,
which could be done with filters and similar. Perhaps not even a bad
idea. Some things are useful for convenience and perhaps even
performance. The balance needs to be good, and I think if a feature
is in there, it should exist in completeness.
That's just my perspective as a developer but obviously you are the
designers behind the extension, so it is your call which features you
feel are important and which not.
/ http://www.fishpool.com/~setok/