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

The bc committee tabled the enumerate extension discussion until AOP discussions began in the ec. I have started the enumerate extensions proposal (skeleton) and have not focused on it pending further AOP discussions. My strong desire is to see MI, AOP, and enumerate extensions get into 1800-2012. These would all be significant upgrades requested by end users. I don't care how we focus the discussions in the committee to enable this. It's worth mentioning that the bc committee is looking for issues to work on and enumerate extensions is one possibility. Given that, I think an initial AOP discussion here in the ec will at least jump start the enumerate discussions again in the bc.

-Tom

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Jonathan Bromley
Sent: Monday, March 21, 2011 12:57 PM
To: Mehdi Mohtashemi
Cc: Gordon Vreugdenhil; sv-ec@eda.org
Subject: 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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.