Re: [sv-ec] rules for overriding virtual method

Daniel,

The original intent, at least in some quarters, was that the
override must be essentially token-equivalent.  I don't know
if anyone is really following that intent since that breaks
down in the presence of out-of-block definitions for parameterized
classes which use the same terminology and is a pain in terms
of handling "obviously identical" overrides when renaming
typedefs and similar are present.

My interpretation is that the names and directions must be
identical and the types must follow the 6.22 rules for matching.

Gord

Daniel Mlynek wrote:
> My doubt can be expressed in example like below - is it legal to 
> override logic with reg (both are matching types)
> virtual class BaseClass;
>      pure virtual function int test(logic aa);
> endclass
> class DerivedClass extends BaseClass;
>      function int test( reg aa );    
>      endfunction   
> endclass
>  
>  
> DANiel
> 
> ------------------------------------------------------------------------
> *From:* owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] 
> *On Behalf Of *Daniel Mlynek
> *Sent:* 10 lipca 2008 15:20
> *To:* 'SV-EC'
> *Cc:* 'Marcin Skrobol'; 'Piotr Winter'
> *Subject:* [sv-ec] rules for overriding virtual method
> 
> LRM says:
> "Later, when subclasses override virtual methods, they shall follow the 
> prototype exactly by having *matching* return *types *and *matching* 
> argument names, *types*, and directions. It is not necessary to have 
> matching default expressions, but the presence of a default shall match."
>  
> I'm not sure if statement : matching type in above context was used to 
> refer term defined im lrm as "matching type" chapter 6.22 or just for 
> english meaning on this word. My doubts are because in one 
> sentence there are used : mathchig name, matching type, matching 
> direction. etc..
>  
> Maybe it should be rewrtiten-reworded to make it clear.
>  
>  
>  
> DANiel
> 
> -- 
> 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* <http://www.mailscanner.info/>, 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.