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

BTW, if the rules are expressed in terms of satisfying the requirements for a virtual method override, then I think that allows covariant return types for classes implementing an interface class. Covariant return types satisfy those requirements.

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

If we need to add anything to 8.25.6.1, I think that it would
sufficient to say that a prototype in an interface class must be
"virtual override compatible" with the prototypes in the classes that it
extends. The "conflict" rule then gives the right outcome by requiring
a prototype in potentially conflicting scenarios (where more than one
unique prototype is visible).

I definitely agree with Steven that Brandon's example of having a later
"D" influence earlier inheritance is not Ok. My (minor tweak) above
would make that clear.

Note that I do think something like the following refinement to
Brandon's example should be legal:

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

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

       interface class C extends A,B;
          pure virtual function C func();
       endclass

       class D implements C;
           virtual function D func();
              func = new();
           endfunction
       endclass

It isn't spelled out that "covariant" types rules should
apply to interface class / class relationships, but it
doesn't seem much of a stretch to me to believe that
it does. That would only apply to how D::func relates;
I believe that the C::func prototype would be both
required given the conflict rules and legal due to
covariant overrides since C is a proper subtype of both
A and B. It is implied (at least) that a "D" return for
a "C" interface class should be legal (it is certainly
legal for direct assignment which is essentially what
the covariant rule means).

In the above it is clear that any call (A::func, B::func,
C::func, D::func) has a well-defined type, is compatible
with super class requirements, and is safe to use in
a statically typed scenario.

I would definitely oppose any interpretation that would
require the typing of "C" without such a prototype that
was "locally" determined to be legal.

Gord.

On 9/9/2011 3:26 PM, Steven Sharp wrote:
> 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.
>
>

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