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