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

I agree that you could not have a legal implementing class in this case. But it should be illegal even if there are no implementing classes. If someone defines a set of interface classes for somebody else to implement, any mismatches should be caught even before the implementations are provided. To provide a concrete example

interface class A;
  pure virtual task t (int foo, real bar);
endclass

interface class B;
  pure virtual task t (int bar, real foo);
endclass

interface class C extends A, B;
endclass

I believe that the existing text would not consider this a mismatch, and it should. Tools should be allowed to recognize this as an error where the two meet, rather than having to suppress the error until the point where the interface class is implemented.

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

On 9/9/2011 9:54 AM, Steven Sharp wrote:
> 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.

But it doesn't matter that we don't apply the rules to the interface
classes in the conflict rules. The existing rules are that an
implementing class
must have an "override compatible" method for all implemented methods.
That includes from *all* implemented classes. So if all interface class
methods are "compatible" with the implementation, how can
any of them have a name conflict with each other in the args?
At least one of those would be incompatible with the implementing
method.

I really don't want to add this into the "conflict" rules.

Gord.

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