[sv-cc] FW: [sv-champions] Email vote - Ending December 13th

Shalom-
Thanks for these inputs/corrections on the Mantis 1477 proposal. See my comments interspersed below ("CB>").

I have uploaded a new revised proposal with corrections, and for benefit of all I have included this text and additional explanations for changes in my note there.
Regards,
Chuck Berking

           
Chuck Berking | Member of Consulting Staff | Cadence
P: 978.262.6522 M: 603.253.9130 www.cadence.com
 
 
 

-----Original Message-----
From: Francoise Martinolle
Sent: Thursday, December 16, 2010 10:21 PM
To: Chuck Berking
Cc: Charlie Dawson; sv-cc@eda.org; Bresticker, Shalom
Subject: FW: [sv-champions] Email vote - Ending December 13th

Chuck,
 
you have some champions feedback on the proposal.
Francoise
    '
-----Original Message-----
From: owner-sv-champions@eda.org [mailto:owner-sv-champions@eda.org] On Behalf Of Bresticker, Shalom
Sent: Thursday, December 16, 2010 2:20 PM
To: Bresticker, Shalom; neil.korpusik@oracle.com; sv-champions@eda.org
Subject: RE: [sv-champions] Email vote - Ending December 13th

I complete my vote by approving 3135 and opposing 1477.

I did not review 1477 completely, but in what I did review, I have some problems and need some clarifications before I can approve it:

Minor editorial: in the changes to 37.15 on page 3, the paragraphs beginning "A ref obj may be obtained ..." should be labeled as detail "2)".

CB> This edit shows a *replacement* for detail #1, which should remain as such. I.e., there is no new detail coming before it, so this should remain #1.

Minor editorial: in the changes to 37.15 on page 4, the detail paragraphs labeled 4 and 5, should be 5 and 6.

CB> Agreed- I have made this change.

Question: This is not part of the proposal, but in the typespec diagram in 37.23, "class typespec" is not bold. Is that correct?

CB> Yes- this is intentional. The "class typespec" object is shown bolded in 37.28, where it is more fully defined.

Minor editorial: In the code examples in the new sections 37.27 and 37.28, on pages 8-10, a large number of keywords need to be made bold.

CB> Yes- corrections have been made.

Question: In the changes to 37.28 and 37.29, "ref obj" was replaced by "virtual interface var". However, in 37.27 (page 11), "ref obj" was simply deleted. Is that correct?

CB> Yes- I originally thought this was an overlooked inconsistency myself, but I now realize this was intentional (see detail #6 added for section 37.12 on p. 1 for rationale). Continuing to allow interface decl iterations (now virtual interface var iterations) was misleading, since class defn objects are "lexical" contexts.

Probable error: In 37.28 in the LRM, "vpiInterfaceDecl" appears in detail 2. I speculate that it should be deleted.

CB> Yes- good catch- I agree, and have added this change.

The change to "#define vpiVirtual" on page 20 adds the comment "Deprecated". However, vpiVirtual is used also in the diagrams for classes (37.27), methods (37.37), and constraints (37.30). So is it correct to label it "Deprecated"?

CB> No- I agree. It is still used for methods and constraints, so it should not be labeled as such (change made).

Shalom

> -----Original Message-----
> From: owner-sv-champions@eda.org [mailto:owner-sv-champions@eda.org]
> On Behalf Of Bresticker, Shalom
> Sent: Monday, December 13, 2010 10:01 PM
> To: neil.korpusik@oracle.com; sv-champions@eda.org
> Subject: RE: [sv-champions] Email vote - Ending December 13th
>
> As I was travelling, I did not have time to look at three big issues:
> 2412, 3135, 1477.
>
> I approve all the others.
>
> Shalom

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

--
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.