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

- 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".

[MM] We could ask for more example usage in this regard to show the use
   model.

[mastrick] Other aspect-oriented implementation have before, after and
around, so perhaps that is reason enough to include all of them. In
AspectJ, around is much more powerful than before or after, allowing one
to change values of parameters or return values. So if one does not
want so much "rope", one would choose before or after. One could
certainly achieve all functionality specified in this document with
around, so there is a reasonable argument to provide only around and not
have substantially similar functionality in a different construct.

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Mehdi Mohtashemi
Sent: Monday, March 21, 2011 4:19 PM
To: Jonathan Bromley; Alsop, Thomas R
Cc: Gordon Vreugdenhil; sv-ec@eda.org
Subject: RE: [sv-ec] uploaded a proposal for mantis 3002

Jonathan,
thanks for your quick review, I wanted to get the first version to
the committee and get a chance to quickly introduce it next week, that
may shed more light on this. Anyhow, my brief replies are below, we
can certainly go over these during the meeting as well.

-----Original Message-----
From: Jonathan Bromley [mailto:jonathanbromley@ymail.com]
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.

[MM] the placeholder is what I was referring to at this point, Tom A
     also responded on this.

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).

[MM] In general the format proposed follows a similar to AspectJ. It
     may not be intutitively obvious as you mention, specially if there
     are multiple advices, however it is defined in the context of
     scoped advices/aspects.
 
- The interaction of AOE with class inheritance is shown only by
example, and I'm not certain that it's fully defined.

[MM] we shall work on expanding this in the next versions.

- 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?

[MM] It is mentioned, applies to all specializations:
    'The aspect extensions for a generic class would apply to any and
      all specializations of the 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.
[MM] We will finalize interface classes, I agree we should be careful
   and pay attention to this and other proposals touching these areas.

- 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).

[MM] The AOP extensions proposed serve specific purpose for the
verification
   engineers and users are requesting it for those purpose, we can
discuss
   the 'when inheritance' as well in this context.

- 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".

[MM] We could ask for more example usage in this regard to show the use
   model.

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.