RE: [sv-ec] Vote on #1356 on 8/29 - please review by 8/24

Thanks for all the feedback. See below (especially nit 1):

From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Friday, August 19, 2011 12:55 PM
To: Tipp, Brandon P
Cc: sv-ec@eda.org
Subject: Re: [sv-ec] Vote on #1356 on 8/29 - please review by 8/24

I still don't like the term "interface inheritance" in the introductory
sentences:
     This interface inheritance allows classes to support common
     behaviors without sharing any implementation.
[Tipp, Brandon P] I agree. Changed to "... interface implementation ..."
Looking for "inheritance" throughout the document, Diamond Inheritance is used to both describe diamond inheritance into an interface class (which is truly inheritance) and diamond implementation of the same interface class. Do you have any issues with the wording there?

Most of the similar terminology has been fixed; I'd really like this
one to be fixed as well ("This relationship to interface classes allows...").
[Tipp, Brandon P] I couldn't find the text "This relationship to interface classes allows..." in rev 9.

A few other nits:
  1) isn't "pop_front()" a function method returning a value?
       myFifo.pop_front(get); should be get = myFifo.pop_front();
       shouldn't it?
[Tipp, Brandon P] Strange... in the LRM, the definition of pop_front() is to return the popped element, but every example of pop_front() in the LRM indicates that the popped element is an output/reference parameter passed to pop_front. I'm not sure what to do about that.

  2) I don't think that the parameter sequence:
            Fifo#(type T = logic, DEPTH = 1)
       is correct. "DEPTH" would be considered a type parameter
       unless "parameter" or an explicit type (say "int") was given.
[Tipp, Brandon P] updated to add int in various locations throughout

  3) in the xfifo example, there is an "endtask" for the void function
      put rather than "endfunction"
[Tipp, Brandon P] fixed

  4) at the end of 8.24.2, I think your example and discussion are
       incorrect. The last paragraph is:
           The non-virtual function f() in BaseClass does not fulfill the
           requirement to implement IntfClass. This instead results in
           a method name conflict in ExtClass (see section 8.25.5.1).
      Why is there a name conflict? The name "f" in ExtClass
      hides the name from BaseClass and satisfies the prototype
      from IntfClass. I believe that the example should be legal. I think
      that the earlier discussion and example meant to show the
      difference with the previous example and should likely just
      not have the definition of "f" in ExtClass at all. Then drop the
      very last discussion sentence since that is just incorrect.
[Tipp, Brandon P] Changing the 2nd sentence to "the declaration of f() in ExtClass hides f() in base class while simultaneously satisfying the requirement to implement f() from IntfClass."

 5) In 8.25.5, the sentence that I've previously objected to
      is still there:
             It shall be an error to cast from a source handle that
             is null. (See section 8.15 Casting)
      Casts from a null literal is legal. For regular classes,
      it is not an error if the static class type of the source
      is a supertype of the target (ie. if the $cast is not
      required but is used). The same should be true here.
      If I have Intf_base extends intf_super and $cast from
      a null intf_super to the intf_base, that should be legal.
[Tipp, Brandon P] I must have missed your previous comments and/or thought that Tom took care of any issues. There are a lot of special rules here regarding null that I'd rather not rehash. Changing this to "Casting from an interface class handle that is null is handled in the same manner as casting from a class handle that is null. (See section 8.15 Casting)"

 6) In 8.25.6.2, the types PUT_T and GET_T are used in the
     example. I think both of those need to be just "T".
[Tipp, Brandon P] Fixed

That is all I've noticed in the time that I've had to take
another look.

It would be good for someone else to take a thorough
look at the examples as well to make sure I haven't overlooked
any other little errors.

If the above are addressed, I think that I'd be willing to
live with any other residual things that I might have missed yet.
Have to leave some fixes for the next PAR; just wouldn't
be 1800 otherwise...

Gord.

On 8/19/2011 11:23 AM, Tipp, Brandon P wrote:
All,

As a reminder, there will be a vote on 1356 at the next SV-EC meeting. Please review the rev9 document by Wednesday 8/24 so that there's time to incorporate any feedback. At this point, I don't expect anything more than relatively minor changes and editorial feedback since we've been discussing every detail of this proposal for well over a year.

Thank you,
Brandon

--
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<mailto:gordonv@model.com>
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.