No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Improvement proposal for instfilters and guards
From: Eckhard Lehmann <eckhardnospam_at_gmx.de>
Date: Fri, 30 May 2008 20:18:56 +0200
Hello Gustaf,
When I read it right (I have little idea about CLOS and not much experience with LISP...), this is exactly what I mean. Just a piece of code that is called whenever a certain method of an object is called and which can serve as kind of "observer" for this method.
One thing comes to mind since I play around with Tclhttpd and a persistency framework: Tclhttpd maintains sessions as safe slave interpreters. These interpreters must know about persistency objects in the server, so it is necessary that
- whenever a persistency object is created, a command alias for it must be created in certain sessions (interpreters)
- whenever a session is created, certain persistency objects must be "informed" (-> a command alias for them must be created in the new interpreter).
- whenever a session is destroyed, it's alias must be removed from all persistency objects that contain it.
It involves interception of several methods and attributes, which I currently do with instfilters and instfilterguards. But it would be simpler if the filter is optionally just called on one method. I am using different filters for different methods anyway, because it avoids large [switch] statements.
If that can be implemented with mixins, fine. I was seeing mixins more in the context of code reuse as an alternative to inheritance, and not as an interception technique.
--
Eckhard
Date: Fri, 30 May 2008 20:18:56 +0200
Hello Gustaf,
However, can you tell more about your use-cases?
I was thinking a few times about providing interceptors
for single methods, similar to the method combinator :around
in CLOS.
When I read it right (I have little idea about CLOS and not much experience with LISP...), this is exactly what I mean. Just a piece of code that is called whenever a certain method of an object is called and which can serve as kind of "observer" for this method.
One thing comes to mind since I play around with Tclhttpd and a persistency framework: Tclhttpd maintains sessions as safe slave interpreters. These interpreters must know about persistency objects in the server, so it is necessary that
- whenever a persistency object is created, a command alias for it must be created in certain sessions (interpreters)
- whenever a session is created, certain persistency objects must be "informed" (-> a command alias for them must be created in the new interpreter).
- whenever a session is destroyed, it's alias must be removed from all persistency objects that contain it.
It involves interception of several methods and attributes, which I currently do with instfilters and instfilterguards. But it would be simpler if the filter is optionally just called on one method. I am using different filters for different methods anyway, because it avoids large [switch] statements.
If that can be implemented with mixins, fine. I was seeing mixins more in the context of code reuse as an alternative to inheritance, and not as an interception technique.
--
Eckhard