> > For me there are 2 types of aspects: typed ones,
> > detyped ones.
> > Detyped ones are the system ones.
> What you are saying here is that many generic
> aspects are, roughly speaking, typed to Object.
> There's no doubt that's true. But note that:
> - that's still statically typed, for example the
> e code
> in question is sure it isn't going to get an
> an unboxed
> - just because some aspects are that generic
> doesn't mean that all will be, especially down
> the road when you open this up to users
We are talking about the chain of responsibility GOF pattern with generic signatures so that you can dynamically weave them together. Think "invoke".
One other way to think about the lack of type is the fact that users don't need to be talking to the cache interceptor to get the benefit, nor to the transaction one. For system aspects it is very clear that the highest level of reuse are on purely orthogonal aspects with no type.
> - and if you don't get static typing in from the
> he start,
> your unlikely to be able to add it later as a
> compatible change
negative. Think security, think tx, they are truly orthogonal concerns, we have been doing this in jboss for ever now.
> aspect that is specific to a certain system, I get
> the benefits of static typing that Java programmers
> are familiar with.
The benefits are not really needed at the system level (again I am not arguing typed interceptors as user level constructs aka composition aka multiple inheritance in java). One of the few cases I can think of clearly is the 'read-ahead' case.
Right now we configure that through a static xml file that configures the "persistence engine" when really itis a property of the call and GUI (how many rows do you want to display). There are 2 ways to do this
which assumes composition of the typed aspect on the end user object so that a dynamic typecast would result in that call being supported. Also this assumes XML configuration to enable proxy creation a la bill to have the "introduction" put there, man so much lingo to describe something really simple and visual.
BTW I think this would be a kick ass LANGUAGE feature that when you cast an object to a certain type, instead of saying "aaaaa I don't like it, classcast exception" the system makes a dynamic composition of that system aspect (if it is a system aspect that the user is requiring) and offer that dynamically... today once the 'introductions" are set in the class definition, they are set, only detyped ones can be weaved at runtime (e.g. cache interception) and that is a clear advantage of detyped system interceptors.
That language must support :dynamic typing.