RE: [sv-ec] Abstract classes and virtual methods

I agree with the identifier names needing to match. In fact I had made
that argument to someone who wanted them not to match. I forgot to
update my proposal.

I don't about default values needing to match, since the default value
is always resolved from the declarations perspective. Maybe we need to
say the presence of a default needs to match, but not the expression
itself.

Dave

> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Friday, January 20, 2006 3:40 PM
> To: sv-ec@eda.org; Rich, Dave
> Subject: Re: [sv-ec] Abstract classes and virtual methods
> 
> 
> >From: "Rich, Dave" <Dave_Rich@mentor.com>
> 
> > 3.	We need to clarify what a matching prototype for virtual method
> > is. This is an erratum. I am proposing that types must match, but
formal
> > identifiers and defaults do not need to match.
> 
> Agreed.  This is very unclear.  However, I think the matching needs to
> be closer than you have proposed.
> 
> The formal identifiers need to match.  It wouldn't matter if we only
> had the positional syntax for passing arguments.  But SystemVerilog
allows
> passing arguments by named connection.  That becomes a problem if
> different overriding methods have different formal names.  What would
> you do if the actual method called did not have one of the named
> arguments,
> or used the same name in a different position?  Clearly you don't want
> to be checking argument names at runtime, to produce errors or decide
> which formal to pass each actual to.  You could resolve the names to
an
> argument position based on the type of the handle at compile time, and
> then use that position to pass to the corresponding (possible
different
> named) argument in the actual method called.  But this is potentially
> confusing.  The proper solution is to require the formal names to
match.
> 
> Default values should match also.  This allows compilers to resolve
the
> default values at compile time for efficiency, if desired.  It also
> avoids possible confusion about what default value is being used.
> 
> Steven Sharp
> sharp@cadence.com