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

Brandon, for your #1, it is not sufficient to show an example of a conflict. The LRM must specify exactly what constitutes a conflict. It fails to specify that a mismatch in argument names or directions or presence of a default is a conflict. I agree with Gord that this is specified for a non-interface class that implements multiple interface classes, by the statement that the non-interface class is required to provide implementations that satisfy the requirements of a virtual method override. But this is not specified for interface classes that extend multiple interface classes. It needs to be.

On your #2, I interpret the proposal as already stating that this is an error. However, this is unclear. The fact that this is unclear is an additional part of the problem.

8.25.6 mentions two situations that can result in getting the same name twice: implementing multiple interface classes, and an interface class extending multiple interface classes.

Section 8.25.6.1 seems to be talking mostly about non-interface classes implementing multiple interface classes. If it doesn't apply to an interface class extending multiple interface classes, then this part has been left out and needs to be specified. If it does apply to interface classes, then it is still incomplete, because it doesn't specify that a mismatch in argument name or direction is an error for those.

I will also point out that if it applies to interface classes, then your example for #2 is already an error according to the proposal. Interface class C inherits func from interface classes A and B, and the return types are incompatible. You are suggesting that it waits until there is an implementation, and then checks the return type against the prototypes in both interface classes, and allows them if they are covariant. But the proposal doesn't say this. It says the identifiers are merged into the same name space at interface class C, and that this conflict must be resolved there.

If you are expecting covariance to be allowed, then there is an additional problem. If we eliminate the intermediate interface class C, and have the non-interface class declare that it implements A and B directly, I don't think the current specification allows covariance. In other words, if we have

interface class A;
  pure virtual function A func();
endclass

interface class B;
  pure virtual function B func();
endclass

class D implements A, B;
  virtual function D func();
    return this;
  endfunction
endclass

which is similar to saying that class D implements C, I don't think the wording in the current proposal allows this.

It is fine by the statement that the non-interface class is required to provide implementations that satisfy the requirements of a virtual method override. The return type of the implementation is assignment compatible with the return types of both prototypes. But the wording in 8.25.6.1 is stricter, probably unintentionally. It says that if the return types of the methods involved in a method name collision are of incompatible types, an error shall occur. The methods involved in the name collision here are A::func and B::func, and they have incompatible return types.

If this stricter requirement was unintentional, then this is a further problem with the proposal. I didn't raise this as an issue because a stricter requirement still works in the language, though it might cause problems for methodologies you have in mind.

-----Original Message-----
From: Tipp, Brandon P [mailto:brandon.p.tipp@intel.com]
Sent: Friday, September 09, 2011 1:49 PM
To: Steven Sharp; Gordon Vreugdenhil
Cc: Mehdi Mohtashemi; sv-ec@eda.org; Tipp, Brandon P
Subject: RE: [sv-ec]Email Vote: Response requested by Friday Sep 9 2011 8:00am [PDT]

Steven,

Your original proposal was just in regards to adding method arguments to section 8.25.6.1. Now we are getting into two separate discussion

1) the broader topic regarding all the ways that you can have an unresolvable method name conflict
2) state that it is an error if an interface class extends two interface classes with "incompatible" method prototypes

With regards to item #1, I would argue that the proposal was simply showing one example where a conflict might be impossible to resolve. Perhaps a change in the wording to that effect would satisfy you?

With regards to item #2, I think that you are opening a big can of worms. What if you have this:

interface class A;
  pure virtual function A func();
endclass

interface class B;
  pure virtual function B func();
endclass

interface class C extends A, B;
endclass

Is there a conflict in C or not? If somewhere in the design there is a class which implements C or both A and B, then you will be able to successfully implement C. If not, then you can't.

-Brandon

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Steven Sharp
Sent: Friday, September 09, 2011 10:23 AM
To: Gordon Vreugdenhil
Cc: Mehdi Mohtashemi; sv-ec@eda.org
Subject: RE: [sv-ec]Email Vote: Response requested by Friday Sep 9 2011 8:00am [PDT]

The same issue arises for argument directions. And it arises for default values, which should match by the rules in 8.25.8. Mismatches should be caught at the point where the two method names are "merged" in a derived interface class, not deferred until an implementation is seen.

-----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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.