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

On 8/19/2011 1:44 PM, Tipp, Brandon P wrote:
>
> 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?/*
>

Nope, the rest of the wording was fine I think. I did the
same search and considered all the uses.

> *//*
>
>
>
> 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./*
>

That text was actually my suggestion for the "interface inheritance"
wording. But I'm fine with your change.

> *//*
>
>
> 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 2^nd sentence to "the declaration of
> f() in ExtClass hides f() in base class while simultaneously
> satisfying the requirement to implement f() from IntfClass."/*
>

That is fine.

> *//*
>
>
> 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)"/*
>

I guess that is Ok. It leaves a bit to one's imagination
but I also don't want to try to regurgitate full rules
at that part of the LRM. So I can live with that.

If you need me to generate a new pdf, feel free to send
me the document and I'll take care of that.

Gord.

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