OK, I understand the intent of that paragraph before the example now. It was intended as a restating of a consequence of the earlier rules. Your rewording sounds like it should work for that.
That still leaves us with #2. There is not an adequate description of the rules when an interface class extends multiple interface classes, and inherits the same method name from both.
8.25.6 says that the identifiers are merged into a single name space, and that the same identifier name can be inherited from multiple name spaces simultaneously creating a conflict which must be resolved. This statement is applied to both classes implementing multiple interface classes and interface classes extending multiple interface classes. The next section is on Method Name Conflict Resolution. The implication is that the rules in 8.25.6.1 apply to both cases. But those rules don't really handle the interface class case, leaving the reader to extrapolate from what is there.
In the non-interface class case, you end up with a single method implementation that must satisfy the requirements of all methods that it implements.
In the interface class case, I assumed that after the merge, you end up with a single method prototype. In order for it to match both base interface classes, the prototypes in both base classes must match each other. This impression is reinforced by the problematic statement for #1, which says that the methods involved in a method name collision must have compatible types.
If I understand you correctly, the actual intent is that the derived interface class inherits multiple method prototypes for the method name, one from each base class, and that an implementation must satisfy them all. This concept of a single interface class type having multiple prototypes for a single method is a radical departure from any existing class functionality. It is not at all obvious, and yet there is nothing in the proposal that indicates it.
Perhaps this isn't the way you think about it, or would want to describe it. You apparently want the derived interface class to require implementations to satisfy the requirements of multiple different virtual method overrides, one for each prototype from a base interface class. This needs to be described somehow.
Once you have that concept, then conflicts are conceptually not detected until the implementation, when it doesn't satisfy one or more of the prototypes. As you say, there may be cases where you could determine earlier that a conflict is inevitable. The proposal could allow those to produce an error earlier. It could spell out cases that must or could be detected earlier, or leave that to the tools (though this would make it undefined whether certain cases with no implementations would produce errors or not). Obvious cases would include having the wrong number of arguments, or the wrong names or directions.
-----Original Message-----
From: Tipp, Brandon P [mailto:brandon.p.tipp@intel.com]
Sent: Friday, September 09, 2011 7:10 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]
I had intended that example as simply being an example of a case where you cannot satisfy the requirement to provide a single implementation which simultaneously satisfies the requirements of both interface classes. I did not mean to introduce a new strict rule. If I had not said that the return type collision is an error, then the simple fact that the ClassA::funcBase() method profices a valid override of IntfBaseA::funcBase, but is not a valid override of IntfBaseB::funcBase would result in an error as already stated elsewhere in the proposal. So in that respect, the language in the proposal introduced a stricter requirement than what is allowed by "valid pure virtual method override". It should be updated. New paragraph before the example:
It is possible to have a method name conflict which cannot be resolved within a subclass. For example:
New paragraph after the example:
Although ClassA::funcBase() follows the virtual method override rules for IntfBaseA::funcBase(), it does not simultaneously follow the virtual method override rules for IntfBaseB::funcBase().
On #2, it can be very difficult to determine if an extended interface class is inheriting completely incompatible methods. Assuming the change above:
package intf_pkg;
interface class A;
endclass
interface class B;
endclass
interface class AA;
pure virtual function A func();
endclass
interface class BB;
pure virtual function B func();
endclass
interface class AABB extends AA, BB;
endclass
endpackage;
import intf_pkg::*;
class C implements A, B, AABB;
virtual function C func();
return this;
endfunction
endclass
When you compile intf_pkg, it might look like there is a un-resolvable conflict in AABB, but if you look at class C, it's actually possible to resolve the conflict. The tool could only figure out that there's a problem with AABB after elaborating the entire design to see that there is no single class which implements both A and B. If there was a problem, such as class C not implementing A, then you'd get an error in class C anyway.
As an alternative, I could add wording to the top of 8.25.6 that "Name conflicts must be resolved at the point where the conflict occurs, even if the conflict arises in an abstract or interface class." That wording would result in an error at AABB above that could easily be determined by a tool because the name conflict over func is not resolved at that point, regardless of whether or not it might be possible to provide a valid override further down the road.
-Brandon
-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com]
Sent: Friday, September 09, 2011 3:26 PM
To: Tipp, Brandon P; 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]
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.Received on Fri Sep 9 16:58:47 2011
This archive was generated by hypermail 2.1.8 : Fri Sep 09 2011 - 16:58:49 PDT