RE: [sv-ec]Email Vote: Response requested by Friday Sep 9 2011 8:00am [PDT]

Comments below:

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Friday, September 09, 2011 11:09 AM
To: Steven Sharp
Cc: Mehdi Mohtashemi; sv-ec@eda.org
Subject: Re: [sv-ec]Email Vote: Response requested by Friday Sep 9 2011 8:00am [PDT]

I don't think it is necessary to add that. And if you do, you'd
have to also add types, etc. to the the definition of "conflict".

SES: I believe the existing rule already covers types. It just doesn't cover the names.

The reason I don't think that it is necessary is that we already
have the following in 8.25:

     This creates a requirement for the non interface class to
      provide implementations for a set of methods which shall
      satisfy the requirements of a virtual method override

SES: This rule only applies to a non-interface class providing implementations. But 8.25.6.1 is also specifying the rules for an interface class extending multiple interface classes. Perhaps there is some other text that applies in this case, but this text doesn't. You could try to apply the standard rules for classes extending superclasses, except that interface classes already don't follow those rules in at least one way: they can extend multiple interface classes.

It is impossible to satisfy those requirements if there are
methods with different formal argument names (or types
other than the now legal covariant return types).

The "conflict" rules are to avoid "surprise" when there
might be two different semantic expectations of methods
with compatible prototypes coming from different base
classes. There is nothing structural (or "prototype matching")
needed by the conflict rules due to the 8.25 requirements.
We could in fact drop the "conflict" rule for method names
completely and still be fine since 8.25 would require that
all the implemented prototypes be "override compatible".

So I think you read a bit too much into the rationale for the
conflict rule and don't think that any change/clarification is
needed in order to have the requirements be tight.

Gord.

On 9/9/2011 7:52 AM, Steven Sharp wrote:
> 1) Mantis 1356 ___Yes _X_No
> http://www.eda.org/svdb/view.php?id=1356
> [Title: Multiple Inheritance]
> [proposal: 1356_Interface_Classes_rev11.pdf]
>
> I would change this to Yes with a friendly amendment to 8.25.6.1 to specify that a mismatch in the argument names for methods involved in a method name collision is also an error. Sorry I missed this in earlier reviews.
>

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.