RE: [sv-ec] mantis item 3279

Jonathan,

The type T1 should not have anything to do with C, (resp T2 and D).
T1 and T2 must belong to the same class hierarchy, whereas C and D may belong to a different class
hierarchy.

Ex: In the example below, T2 is covariant with T1, that means it can be substituted to T1 in a virtual method
override where T1 is a return type or an output argument type.

class T1;
endclass

class T2 extends T1;
endclass

class C;
      virtual function T1 some_method(); endfunction
   endclass

   class D extends C;
      virtual function T2 some_method(); endfunction
   endclass

 Yes, we need to take into account interface classes that a class can implement.
But first I was trying to get the definition of covariant types for normal classes.
Then we can enhance it for interface classes.

Based on your observations, I am going to attempt to propose a better proposal.

Francoise
       '

________________________________
From: Jonathan Bromley [mailto:jonathanbromley@ymail.com]
Sent: Monday, February 21, 2011 3:28 PM
To: Francoise Martinolle
Cc: sv-ec@server.eda.org
Subject: Re: [sv-ec] mantis item 3279

On 21/02/2011 20:18, Jonathan Bromley wrote:
- Define covariant return types thus:
Consider a class C having some virtual method F with a return or output-argument type T1. If C is assignment-compatible with T1 then an overloaded definition of F, in any class D that is derived from C, may replace type T1 with a different type T2 provided that D is assignment-compatible with T2. An argument or return type that has been replaced in this manner in a derived class is a covariant type.

Curses, I can see an error straight away. Should be "an overloaded definition of F, in any class D that is assignment-compatible with C" to cope with the possibility that C is an interface class and D implements it. (I assume this would also be a candidate for covariance?)

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