Re: [sv-ec] uploaded a proposal for mantis 3002

Mehdi,
> I wanted to bring the work we had done on the AOP proposal
> to the sv-ec attention and get an introduction going, as it
> may possibly help in the sv-bc enum discussions.
You mention enums, and it's certainly true that one of the key enablers
that makes AOP useful in 'e' is the ability to extend enum types, not
just classes. But the current 3002 proposal makes no mention of that.
Is it something that's "in the works" in BC? 2991 is a placeholder for
it but there seems to be no related activity.

Even without consideration of enum extension, I already have some issues
with the existing proposal:

- The interaction of advice with return statements, whether in the
advice or in the original code, is not well defined (it's worth noting
that the corresponding behavior in 'e' is indeed well defined, but it's
far from being intuitively obvious).

- The interaction of AOE with class inheritance is shown only by
example, and I'm not certain that it's fully defined.

- There's no mention of class parameters. Can AOE affect a class's
parameterization? Is it possible to apply an aspect extension to a
specialization of a parameterized class?

- As Mehdi alluded-to in his original email, there's no mention of the
relationship between the AOE proposal and interface classes; that
clearly needs careful attention.

- Unless I've misunderstood, all extensions are static (fully known at
elaboration time); this, it seems to me, much reduces the value of AOP.
I'm sure many users would immediately make unfavorable comparisons with
e's "when inheritance" (dynamic selection of aspect extensions).

- The document doesn't make a very strong case for the "before" and
"after" advice keywords. It seems, from the current description, that
both could be replaced with appropriate use of "around" and "default".

Of course it may be that I've misunderstood some of the intent here;
apologies to the authors if so.

Thanks

Jonathan Bromley

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.