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: Wed, 26 Sep 2001 11:49:33 +0200
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
Date: Wed, 26 Sep 2001 11:49:33 +0200
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
-- 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