[Xotcl] AOP and XOtcl

[Uwe Zdun]

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


-- 
Uwe Zdun
Institute for Computer Science, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun@{xotcl,computer,acm}.org, uwe.zdun@uni-essen.de