[sv-ec] RE: Interface Class Resolutions discussed today

I updated the mantis proposal with the resolutions below. Please see rev2:

http://www.eda.org/svdb/view.php?id=1356

I also noted in the proposal the related mantis issues where appropriate.

Thanks, -Tom

From: Alsop, Thomas R
Sent: Monday, January 17, 2011 12:55 PM
To: sv-ec@eda.org
Cc: Alsop, Thomas R
Subject: Interface Class Resolutions discussed today

Hi Everyone,

Here are the decisions we made today. I'll update the proposal. Let me know if the resolution wording needs improvement.

Thanks for the great progress to date! -Tom

1. Mantis issues 3278 & 3279 (filed by Gord)

2. Type Usage Restrictions - We do not want to allow parameterization of Interface Classes types to be used as the 'implements' argument. Examples below:
class Fifo #(type T = PutImp) implements T;
virtual class Fifo #(type T = PutImp) implements T
interface class Fifo #(type T = PutImp) implements T;
     RESOLUTION - Interface Class parameterization shall not be allowed within classes (see examples above). At the time that an IC is implemented, the implemented type shall be know at the point of reference to be an IC.

3. Nested IC's - Yes or No - (Resolution - IC are not allowed to nest at all, classes can nest in IC's)

a. IC in a class - This can make sense for end users but adds complication.

b. Class in a IC - committee says this makes sense (for now however, let's not allow. Too many use models, can add later)

c. class in a class - already allowed (needed originally to avoid polluting the global namespace and avoids collisions).

d. IC in a IC - Can again make the case where is can be useful but decided to not implement yet. We can always add later.
RESOLUTION - Interface Classes shall not be nested with in any other class type, including other interface classes. Classes shall not nest IC's.

4. Casting of IC types - New mantis item, elaboration time type check or run-time. Checking on $cast parameter to check for type compatibility when the source is null. Mantis 3293 defines what $cast does in general, but will resolve this.

5. Diamond Default Method - RESOLUTION - The actual value of the constant shall be the same on all classes that implement the method. Mantis issues (1584) still open about the scenario of this being a virtual IC types where in polymorphism it's unclear which default value is chosen from either the base class or the extended class.

Thanks, -Tom

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.