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

I agree with Gord, Steven with that explanation would you change
your vote to YES? or keep same NO? Let me know so I can move
forward with the vote count.
Mehdi

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Friday, September 09, 2011 8: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".

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

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.