No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] AOP and XOtcl
From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Tue, 25 Sep 2001 17:40:19 +0200
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 ...
Date: Tue, 25 Sep 2001 17:40:19 +0200
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_at_{xotcl,computer,acm}.org, uwe.zdun_at_uni-essen.de