[sv-ec] interface class extending from multiple interface classes issue.

Tom, Brandon,

I looked up the java specification language regarding name resolution in an interface extending
from multiple interfaces. This is what we discussed at the meeting after Tom had left.
It looks like Java allows an interface to extend from multiple interfaces.
These "super"interfaces can contain members type declarations.
The derived interface may declare a member type in which case it hides the declarations of the same name
from the super interfaces.
Member types from the super interfaces are inherited by the derived interfaces, if one or more super interfaces declare the same member type
name, a simple name of the member type in the derived interface is ambiguous and results in a compiler error.
If the same type declaration is inherited by an interface through multiple paths, it is still considered the SAME type and can be
referred to with a simple name.

Ex1: derived interface class member hides super interface class declaration of the same member type name.

interface class IFC_BASE1;
typedef int myint;
endclass
interface class IFC_BASE2;
endclass

interface class IFC extends IFC_BASE1, IFC_BASE2;
typedef int myint; // this declaration HIDEs IFC_BASE1::myint

endinterface

Ex2: inheritance of super interface member type

interface class IFC_BASE1;
typedef int myint;
endclass
interface class IFC_BASE2;
endclass

interface class IFC extends IFC_BASE1, IFC_BASE2;
virtual task t (myint v); // inherits the member type myint from IFC_BASE1
endtask
endinterface

Ex3: Compiler error for ambiguous reference to multiply defined super interfaces member type

interface class IFC_BASE1;
typedef int myint;
endclass
interface class IFC_BASE2;
typedef long myint;
endclass

interface class IFC extends IFC_BASE1, IFC_BASE2;
virtual task t (myint v); // myint is ambiguous=> compiler error
endtask
endinterface

Ex4: Using scoped names for referencing defined super interfaces member type

interface class IFC_BASE1;
typedef int myint;
endclass
interface class IFC_BASE2;
typedef long myint;
endclass

interface class IFC extends IFC_BASE1, IFC_BASE2;
virtual task t (IFC_BASE1::myint v); // myint is int
endtask
endinterface

Ex5: Member type name coming from different PATHs, legal to use simple name

interface class BASE;
typedef int myint;
endclass
interface class IFC_BASE1 extends BASE;
endclass
interface class IFC_BASE2 extends BASE;
endclass

interface class IFC extends IFC_BASE1, IFC_BASE2;
virtual task t (myint v); // myint is int which is BASE::myint
endtask
endinterface

The current language in 1356 is:

An interface class may be declared to be an extension of one or more other interface classes, meaning that it implicitly specifies all the member types, pure virtual methods and constants of the interface classes it extends, except for any member types and constants that it may hide.

The language in the paragraph above of 1356 proposal does not specifies what happens if more than one
super interface class defines the same symbol.
I think we need to specify this perhaps considering the java specification.

Francoise
       '

________________________________
From: Alsop, Thomas R [mailto:thomas.r.alsop@intel.com]
Sent: Tuesday, May 17, 2011 4:53 PM
To: Francoise Martinolle; sv-ec@server.eda.org
Subject: RE: 1356 comments for page 1 and 2

below...

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Francoise Martinolle
Sent: Monday, May 16, 2011 12:15 PM
To: Francoise Martinolle; sv-ec@server.eda.org
Subject: [sv-ec] 1356 comments for page 1 and 2

Here are some comments for the first 2 pages of the proposal.
I will send more comments on the proposal towards the end of the week.

Francoise
       '

section 8.3 Syntax.
The syntax defines interface class type to be class_identifier[parameter_value_assignment)

Are we not allowing nested interface class types that would need to be refered as class_identifier[parameter_value_assignment] { :: class_identifier[parameter_value_assignment]}
[Alsop, Thomas R] Correct, we are not allowing nested interface classes.

The syntax also disallows $unit::class_identifier [parameter_value_assignment]
[Alsop, Thomas R] That is correct.

Section 8.25

"A virtual class that is implementing an interface class is not required to fully define the methods, however they must be fully defined by descendent classes. "

Does this mean ALL non virtual derived classes?

[Alsop, Thomas R] Your question does not make sense.

This paragraph does not use usual LRM terminology and looks like it has some contradictions.

An interface class may be declared to be an extension of one or more other interface classes, meaning that it implicitly specifies all the member types, pure virtual methods and constants of the interface classes it extends, except for any member types and constants that it may hide.

I think it meant to say:

"An interface class may be declared to extend from one or more interface classes. Such an interface class inherits only the pure virtual methods; the type and constants declarations are not inherited."

[Alsop, Thomas R] Gord has us add this. We had to be careful in how we worded this to 'hide' the member types and constants. Come to think of it we should probably remove all mention of constants because we do not allow them. Additional restriction we added.

 Next paragraph says 2 things:

1. polymorphism applies to interface classes

  The first sentence refers to section 8.21 but I dot see any changes for section 8.21

Section 8.21 should be updated

I think that the sentence :

A variable whose declared type is an interface class type may have as its value a reference to any instance of a class which implements the specified interface class (see 8.21 Polymorphism).

would be better written as:

A class variable instance of a class type that implements an interface class can be assigned to a variable of that interface class type.

[Alsop, Thomas R] The original description is more clear to me.

2. a class or its super class must be declared to "implement" an interface class

Perhaps better wording would be:

It is not sufficient that the class (happens to) implement all the pure virtual methods of the interface class; the class or one of its superclasses (must) shall (actually) be declared to implement the interface class through the implements keyword, or else the class is not considered to implement the interface class.

[Alsop, Thomas R] Fixed.

The first following example needs to be enhanced. I'd like to see an actual implementation for the tasks

put and get in the class FIFO, not just a comment.

[Alsop, Thomas R] What would be the purpose? It will just add unnecessary unrelated code into the example.

If the parameter MyPutSignal is not used in the interface class PutImp, let's remove it.

[Alsop, Thomas R] Removed.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.