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.

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...").

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?
   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.
   3) in the xfifo example, there is an "endtask" for the void function
       put rather than "endfunction"
   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.
  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.
  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".

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