Hi,
I guess there are interesting applications of XOtcl filters and mixins to aspect oriented programming? Are there any publications or work on this subject?
Thanks,
Hi,
in the forthcoming XOTcl release will be several new filter features ... I've already reported on the obj-filters. Another feature we have ready are "filter guards". A filter guard is a condition whether a filter will be executed or not. It is registration-centric, thus you can append the conditions to the filter registration, example:
A instfilter {filter-1 {filter-2 {[self calledclass] == "::FigureElement"}}}
that means: filter-1 will always be executed (as in 0.85) .. filter-2 only wenn self calledclass is ::FigureElement. Of course, you can call methods from the filter guard, filters will not be applied to these calls.
Moreover, we have info (inst)filterguard and (inst)filterguard instcommands on Object/Class ...
I've a half-working AOP extension written in about 100 lines of code with this feature. Pointcuts can be defined in instprocs, so that you can do something like:
Aspect PointCutBoundsChecking PointCutBoundsChecking appliesTo {FigureElement Point} PointCutBoundsChecking pointcut setXs { [[self] calls "Point" "setX"] || [[self] calls "FigureElement "setXY"] } PointCutBoundsChecking before setXs {x} { if {$x < 100 || $x > 1000} { error "out of bounds x=$x" } }
I hope to have a first version with the next XOTcl release ...
--Uwe
On Sunday 23 September 2001 12:08 pm, Catherine Letondal wrote:
Hi,
I guess there are interesting applications of XOtcl filters and mixins to aspect oriented programming? Are there any publications or work on this subject?
Thanks,
On Mon, 24 Sep 2001, Uwe Zdun wrote:
in the forthcoming XOTcl release will be several new filter features ... I've already reported on the obj-filters. Another feature we have ready are "filter guards". A filter guard is a condition whether a filter will be executed or not. It is registration-centric, thus you can append the conditions to the filter registration, example:
A instfilter {filter-1 {filter-2 {[self calledclass] == "::FigureElement"}}}
I wonder if it would make sense to allow filters to be objects? In that way filters could become semi-independent entities that can used in various different places by attaching them to other objects, and filtering specific methods. In that way they might more closely follow the direction taken by AOP concepts. Or would mixins be better for this kind of design?
Haven't given it much thought. I'm just rambling :-)
- ---------- = = ---------//--+ | / Kristoffer Lawson | www.fishpool.fi|.com +-> | setok@fishpool.com | - - --+------ |-- Fishpool Creations Ltd - / | +-------- = - - - = --------- /~setok/
On Monday 24 September 2001 11:26 pm, you wrote:
On Mon, 24 Sep 2001, Uwe Zdun wrote:
in the forthcoming XOTcl release will be several new filter features ... I've already reported on the obj-filters. Another feature we have ready are "filter guards". A filter guard is a condition whether a filter will be executed or not. It is registration-centric, thus you can append the conditions to the filter registration, example:
A instfilter {filter-1 {filter-2 {[self calledclass] == "::FigureElement"}}}
I wonder if it would make sense to allow filters to be objects? In that way filters could become semi-independent entities that can used in various different places by attaching them to other objects, and filtering specific methods. In that way they might more closely follow the direction taken by AOP concepts. Or would mixins be better for this kind of design?
Haven't given it much thought. I'm just rambling :-)
Without having given that too much thought either, I think there are three possible paths to make filters objects:
a) make everything in XOTcl an object including procs and instprocs => filters are objects as well
b) make filters special objects which have a method (proc) on them which is the filter. This would be a substantially different model to what we have now. Filter search would have to take place on these objects, filters would not be inherited, linearization of filters would be different, etc. But, of course, we could combine different filters on these objects. This would be closer to cross-cutting concerns in AOP.
c) we could (optionally) return objects by the info methods of a filter which are linked to the filter. Thus the filters would stay what they are, but they can be queried using an object. This is more or less the lightweight object idea discussed on this list before. E.g. there could be a modifier for info, such as: set fi [X info -obj instfilter] puts [$fi set filters] puts [$fi set guards] whereas: X info instfilter returns the usual list. We could as well provide such links to other interesting infos, as for instance the filter callstack info (callingobject, etc.)
--uwe
PS: we have reduced the minimum per-object size to 48 bytes so that such lightweight object become quite feasible ...
On Tue, 25 Sep 2001, Uwe Zdun wrote:
b) make filters special objects which have a method (proc) on them which is the filter. This would be a substantially different model to what we have now. Filter search would have to take place on these objects, filters would not be inherited, linearization of filters would be different, etc. But, of course, we could combine different filters on these objects. This would be closer to cross-cutting concerns in AOP.
Could you not still keep inheritance in this model? The only difference really would be that the filters themselves would be reusable components. If attached to a class, then all class methods, and anything extending the class, will be affected by the filter. Or is there something wrong with this idea?
- ---------- = = ---------//--+ | / Kristoffer Lawson | www.fishpool.fi|.com +-> | setok@fishpool.com | - - --+------ |-- Fishpool Creations Ltd - / | +-------- = - - - = --------- /~setok/
On Tuesday 25 September 2001 06:16 pm, you wrote:
On Tue, 25 Sep 2001, Uwe Zdun wrote:
b) make filters special objects which have a method (proc) on them which is the filter. This would be a substantially different model to what we have now. Filter search would have to take place on these objects, filters would not be inherited, linearization of filters would be different, etc. But, of course, we could combine different filters on these objects. This would be closer to cross-cutting concerns in AOP.
Could you not still keep inheritance in this model? The only difference really would be that the filters themselves would be reusable components. If attached to a class, then all class methods, and anything extending the class, will be affected by the filter. Or is there something wrong with this idea?
no, in principal not ... to clarify things, what you mean is:
Object filters filters proc f1 args { ... } filters proc f2 args { ... }
Class X X instproc xf args {...} X instfilter {xf filters::f1}
- if "::"'s are in the filter name, we only search for procs on objects during filter search.
- [self class] is "" in f1, f2?
- good old instproc filters, such as xf, still work or are all filters object procs?
- what are potential benefits to a Class
Class filters filters instproc f1 args { ... } filters instproc f2 args { ... }
which we use e.g. as superclass or instmixin (what will work fully in the next release)?
--uwe
On Wed, 26 Sep 2001, Uwe Zdun wrote:
no, in principal not ... to clarify things, what you mean is:
Well, as mentioned, I haven't given it any serious thought. I was just speculating to myself out loud.
- what are potential benefits to a Class
Actually this is a valid point. As classes can naturally be dynamically added and removed, the whole AOP logic can be implemented by classes which are just brought into the inheritance chain, and which provide the required filters. In that case I cannot immediately see any benefit in providing the filter as a separate object.
- ---------- = = ---------//--+ | / Kristoffer Lawson | www.fishpool.fi|.com +-> | setok@fishpool.com | - - --+------ |-- Fishpool Creations Ltd - / | +-------- = - - - = --------- /~setok/
On Wednesday 26 September 2001 03:46 pm, you wrote:
Actually this is a valid point. As classes can naturally be dynamically added and removed, the whole AOP logic can be implemented by classes which are just brought into the inheritance chain, and which provide the required filters. In that case I cannot immediately see any benefit in providing the filter as a separate object.
There would some benefit if there is a common class "Filter" for all filters or if you could directly manipulate the filter info that way. I'm not sure yet how to do it the best way, but both features would be quite handy for other XOTcl structures as well.
--Uwe
PS: another issue: there were some requests for new info options on this list. right off the head:
- list of all procs defined for an object (procs + all instprocs up the heritage order) - list of all mixins (mixins+instmixins) for an obj - list of all filters (filters+instfilters) for an obj
Perhaps return certain infos conditionally as ligthweight objects ...
Were/are there any other suggestions?
On Wed, 26 Sep 2001, Uwe Zdun wrote:
- list of all procs defined for an object (procs + all instprocs up the heritage order)
- list of all mixins (mixins+instmixins) for an obj
- list of all filters (filters+instfilters) for an obj
Perhaps return certain infos conditionally as ligthweight objects ...
Were/are there any other suggestions?
A hugely important feature I would like to see in the near future, and one I've asked about before, is for a good C&C++ interface. I know this is not an easy issue to deal with, but for some things it would actually be quite vital. For me, the normal application development model would be to built everything in Tcl/XOTcl first, and then to begin converting critical parts to C if better performance is required.
So what I would need is a semi-standard documented mechanism for adding procs and instprocs to objects from C (and, possibly later, C++) so that the C implementations can rely on the same information about object context and next-chaining as the XOTcl code itself. To take this even further, I may want to implement complete objects in C.
I've given this some amount of thought, but I don't have any really worthwhile suggestions to give as to how best to do this. I just think that now, with 1.0 coming out, is a good time to really put some thought into this. Another reason is that while the language develops I'm sure it will be more and more difficult to specify a complete library for this. With a simple core a library can be built and the extended as new aspects arise that use the same core.
Does this make sense at all?
- ---------- = = ---------//--+ | / Kristoffer Lawson | www.fishpool.fi|.com +-> | setok@fishpool.com | - - --+------ |-- Fishpool Creations Ltd - / | +-------- = - - - = --------- /~setok/
On Wednesday 26 September 2001 05:19 pm, you wrote:
A hugely important feature I would like to see in the near future, and one I've asked about before, is for a good C&C++ interface. I know this is not an easy issue to deal with, but for some things it would actually be quite vital. For me, the normal application development model would be to built everything in Tcl/XOTcl first, and then to begin converting critical parts to C if better performance is required.
that's more or less our opinion as well .. a mature (and documented) C API is VERY important
So what I would need is a semi-standard documented mechanism for adding procs and instprocs to objects from C (and, possibly later, C++) so that the C implementations can rely on the same information about object context and next-chaining as the XOTcl code itself. To take this even further, I may want to implement complete objects in C.
the basic (==OTcl) features are working currently quite well from C, but its not documented. You can use XOTclAddIMethod for inst-commands and XOTclAddPMethod for obj-commands. Take a look at xotclgdbm or xotclsdbm how it can be done.
However, the newer features are still missing (of course, you can use Tcl_Eval ... but that's not yielding the desired performance advantages)
I've given this some amount of thought, but I don't have any really worthwhile suggestions to give as to how best to do this. I just think that now, with 1.0 coming out, is a good time to really put some thought into this. Another reason is that while the language develops I'm sure it will be more and more difficult to specify a complete library for this. With a simple core a library can be built and the extended as new aspects arise that use the same core.
I believe it is actually quite easy to be done, because you just have to add extern wrapper functions for existing static functions. Of course, it is hard to say what is needed ... but we can add more stuff later on ...
Does this make sense at all?
As Zoran suggested: I would say, yes, Yes, and YES :)
To be serious: we'll roll out what we have done now as 0.9 as soon as possible so that you all have a chance to update your applications to the new features. We can give the C API a try for 1.0. If you need something meanwhile, just put it in yourself, send it to us, and we'll incooperate it directly into xotcl.h or xotclInt.h.
Cheers,
Uwe
- ---------- = = ---------//--+ | / Kristoffer Lawson | www.fishpool.fi|.com +-> | setok@fishpool.com | - - --+------ |-- Fishpool Creations Ltd - / | +-------- = - - - = --------- /~setok/
Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
On Thursday 27 September 2001 17:06, you wrote:
On Wednesday 26 September 2001 05:19 pm, you wrote:
A hugely important feature I would like to see in the near future, and one I've asked about before, is for a good C&C++ interface. I know this is not an easy issue to deal with, but for some things it would actually be quite vital. For me, the normal application development model would be to built everything in Tcl/XOTcl first, and then to begin converting critical parts to C if better performance is required.
This is certainly the way to go for many realword applications. we need two things (a) as everybody empahsized a good C-API (b) a conveniant way to integrate c and c++ code.
SWIG is doing quite well on the C side. We have as well started to make a powerful C++ interface, that maps C++ classes into XOTcl classes. This way, it is possible to use C++ classes and objects together with mixins, filters etc., without even knowing the XOTcl C-API. what we have now is that C++ classes can be plugged into the XOTcl class hierarchy (sub- and superclassed, but e.g. no next from c++)
What we did was for SWIG 1.3.6; what we did was mostly the C++ side. we won't have it ready for 0.9. Our code is still full of debug info, some of the code for interfacing c has do be done, some code of the c++ interface relies on the naming conventions of swig, so there is still some work to do. The newest release of SWIG is 1.3.9. if there are volunteers, to help out, these are very welcome.
best regards -gustaf
-
Catherine Letondal -
Gustaf Neumann -
Kristoffer Lawson -
Uwe Zdun -
Zoran Vasiljevic