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

I've uploaded ver10 to Mantis with the Brandon's changes
based on my comments.

Gord.

On 8/19/2011 1:52 PM, Gordon Vreugdenhil wrote:
>
>
> 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

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