Responded to Uwe instead of the list. Here:
Begin forwarded message:
From: Kristoffer Lawson setok@fishpool.com Date: 11 July 2006 19:30:51 GMT+03:00 To: Uwe Zdun zdun@infosys.tuwien.ac.at Subject: Re: [Xotcl] Asserts off/on
On 11 Jul 2006, at 19:24, Uwe Zdun wrote:
The method "check" can be used to turn off assertions. The example from the tutorial:
That is per-object. I am wondering if there is anything that would be for everything.
/ http://www.fishpool.com/~setok/
Kristoffer,
the following might help you... -gustaf
# a little helper Object instproc apply {list args} {foreach o $list {eval $o $args}}
# turn off checking for all objects Object apply [::xotcl::Object allinstances] check ""
Kristoffer Lawson schrieb:
On 11 Jul 2006, at 19:24, Uwe Zdun wrote:
The method "check" can be used to turn off assertions. The example from the tutorial:
That is per-object. I am wondering if there is anything that would be for everything.
On 15 Jul 2006, at 17:00, Gustaf Neumann wrote:
Kristoffer,
the following might help you... -gustaf
# a little helper Object instproc apply {list args} {foreach o $list {eval $o $args}}
# turn off checking for all objects Object apply [::xotcl::Object allinstances] check ""
Except that this only works 'afterwards'. So it doesn't actually help, as I'd still have to apply it after I create objects etc. when really I just want to turn it on at the top of the application and leave it at that.
For the moment I managed this with a filter that is called every time an object is initialised, but I would imagine this the kind of thing that should be handled elegantly by the XOTcl core?
Kristoffer Lawson schrieb:
Except that this only works 'afterwards'. So it doesn't actually help, as I'd still have to apply it after I create objects etc.
i thought you want to turn on checking for all objects (which means existing objects).
when really I just want to turn it on at the top of the application and leave it at that.
For the moment I managed this with a filter that is called every time an object is initialised, but I would imagine this the kind of thing that should be handled elegantly by the XOTcl core?
Why a filter?
in order to turn an checking for objects as you create these, you might use something like the following:
Object instmixin [Class new -instproc init args {my check all; next}]
-gustaf
/ http://www.fishpool.com/~setok/
On 15 Jul 2006, at 17:21, Gustaf Neumann wrote:
Kristoffer Lawson schrieb:
Except that this only works 'afterwards'. So it doesn't actually help, as I'd still have to apply it after I create objects etc.
i thought you want to turn on checking for all objects (which means existing objects).
when really I just want to turn it on at the top of the application and leave it at that.
For the moment I managed this with a filter that is called every time an object is initialised, but I would imagine this the kind of thing that should be handled elegantly by the XOTcl core?
Why a filter?
Hm, well, it was the first thing that came to mind :-) And easy to do anyway.
in order to turn an checking for objects as you create these, you might use something like the following:
Object instmixin [Class new -instproc init args {my check all; next}]
Yeah, giving that some thought, that should work too.
But would it be useful to have this kind of functionality in the core too?
Something like:
Class instcheck all
Kristoffer Lawson schrieb:
Object instmixin [Class new -instproc init args {my check all; next}]
Yeah, giving that some thought, that should work too.
i would not write it, if i were not sure it works :)
But would it be useful to have this kind of functionality in the core too?
well, as long we can do such kind of things with a few lines of code in xotcl i see not need for hacking this into C. xotcl is sometimes criticised for having already a too large set of predefined methods...
greetings -gustaf
On 15 Jul 2006, at 18:02, Gustaf Neumann wrote:
But would it be useful to have this kind of functionality in the core too?
well, as long we can do such kind of things with a few lines of code in xotcl i see not need for hacking this into C. xotcl is sometimes criticised for having already a too large set of predefined methods...
Well yeah, I guess one needs to be careful with that. Certainly there are areas where simplicity is a virtue, and perhaps there are some overlapping areas, but I just thought of it as a pretty natural extension of the current "check" functionality. To me it would feel more natural for a "cover everything" check than for the current per- object style. 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). 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.
Neither of our solutions are really the kind of thing basic coders would come up with.
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/
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.
-
Gustaf Neumann -
Kristoffer Lawson