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

Thanks Neil, I have uploaded v4 with your typos corrected and some of
your suggestions. Comments embedded below for comments I did not take

> -----Original Message-----
> From: Neil Korpusik [mailto:Neil.Korpusik@Sun.COM]
> Sent: Friday, March 03, 2006 6:47 PM
> To: Rich, Dave
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] Abstract classes and virtual methods
> 
> I had the following comments on Dave's latest proposal for mantis
1308.
> 
> 1. Overriding a virtual method
> 
>    Page 1, 1st paragraph, 3rd sentence:
> 
>    I still don't like this sentence. Both Gordon and I have previously
>    suggested different ways to phrase this section. I have tried to
refine
>    my previous suggestion a bit more and now suggest the following.
> 
>    From:
>       "A virtual method shall override a method in all of its base
> (parent)
>       classes, whereas a non-virtual method shall only override a
method
>       in that class and its descendants."
>    To:
>       "The implementation of a virtual method shall override any
> implementations
>       of that same virtual method that were made within any of its
parent
>       class whenever an object of that subclass is accessed through a
> handle
>       to the defining subclass or a handle to any of its base classes.
The
>       implementation of a non-virtual method may only override that
method
>       within the subclass in which it is defined and shall not affect
its
>       parent classes."
[DR>] I don't like this new wording because introduces the concept of an
implementation which won't be introduced until the next section. Also, I
would like to keep virtualness distinct from its implementation.
> 
> 2. Typos - Example on page 1
> 
>    From:
>       $display("A is ",A);
>    To:
>       $display("A is %d",A);
[DR>] Legal Verilog, but not very good style. I made the change
> 
>    From:
>       endfuncion : printA
>    To:
>       endfunction : printA
> 
>    From:
>       $display("B is ",B);
>    To:
>       $display("B is %d",B);
> 
>    From:
>       endfuntcion : printB
>    To:
>       endfunction : printB
> 
>    From:
>       endclass : BasePacket
>    To:
>       endclass : My_Packet
> 
> 3. Example on page 1
> 
>
[DR>] made suggested change and then some
> 
> 4. Results from example on page 1
> 
>    This example uses an overridden property. This makes the example
>    interesting (possibly more interesting than what Dave intended).
> 
>    Sub-clause 7.13 describes overridden members.
>    3rd paragraph:
> 
>          LinkedPacket lp = new;
>          Packet p = lp;
> 
>       In this case, references to p access the methods and class
> properties of
>       the Packet class. So, for example, if class properties and
methods
> in
>       LinkedPacket are overridden, these overridden members referred
to
>       through p get the original members in the packet class. From p,
new
> and
>       all overridden members in LinkedPacket are now hidden.
> 
>    If all of that is true then what is the correct value for the line
>    marked below?
> 
>       For this case a virtual method was redefined in a subclass and a
> property
>       was also overridden by that same subclass definition. If we now
> access
>       that overridden property through a handle to the base class
using
> the
>       virtual method, which value of that overridden property should
be
> used?
> 
>    We need to be explicit about what should be returned in this case
and
> not
>    just rely on an example to define the desired semantics. What is
shown
>    below appears to be in contradiction with 7.13.
> 
>    BasePacket p1 = new;
>    My_Packet  p2 = new;
>    initial begin
>       p1.printA;  // displays 'A is 1'
>       p1.printB;  // displays 'B is 2'
> 
>       p1 = p2;
>       p1.printA;  // displays 'A is 1'
>       p1.printB;  // displays 'B is 4'   <----- is this correct?
> 
>       p2.printA;  // displays 'A is 3'
>       p2.printB;  // displays 'B is 4'
[DR>] This is the correct behavior, or a new mantis item. Search rules
inside a function always start from the definition of that function,
never from the caller's perspective.
> 
> 5. Typos page 2
> 
>    From:
>       In the that
>    To:
>       In that
> 
>    From:
>       having a method body..
>    To:
>       having a method body.
> 
> 6. Sub-clause 7.20
> 
>    The version of the LRM that I am looking at has this as 7.19. I
don't
>    understand why you have changed it to 7.20

[DR>] Because I split old 7.19 (Abstract classes and virtual methods)
into two sections, 7.19 (Virtual methods) and 7.20 (Abstract classes and
prototype virtual methods) 
> 
> 7. Typos page 3
> 
>    From:
>       as show below
>    To:
>       as shown below
> 
> 8. Sub-clause 7.13
> 
>    This may be beyond the scope of this mantis item, but since we are
>    looking at this section of the document, I would like to add a
couple
>    of lines to the example in this section. The existing example
remains
>    the same, just add two extra statements to the end.
> 
>    From:
>       LinkedPacket lp = new;
>       Packet p = lp;
>       j = p.i;           // j=1, not 2
>       j = p.get();       // j=1, not -1 or -2
>    To:
>       LinkedPacket lp = new;
>       Packet p = lp;
>       j = p.i;           // j=1, not 2
>       j = p.get();       // j=1, not -1 or -2
>       j = lp.i;          // j=2                  <---- added this
>       j = lp.get();      // j=-2                 <---- added this
[DR>] This should be another mantis item.
> 
> 
> Neil
> 
> 
> Rich, Dave wrote On 03/02/06 18:57,:
> > New proposal has been uploaded to mantis 1308 to reflect changes to
> > "pure virtual" syntax and to match C++ as stated below.
> >
> >
> >
> 
> --
> ---------------------------------------------------------------------
> Neil Korpusik                                     Tel: 408-720-4852
> Senior Staff Engineer                             Fax: 408-720-4850
> Frontend Technologies - ASICs & Processors (FTAP)
> Sun Microsystems
> email: neil.korpusik@sun.com
> ---------------------------------------------------------------------
>