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 ...