RE: [sv-ec] email ballot: response due by 11:00am PDT Friday May 1 2009

From: Alsop, Thomas R <thomas.r.alsop_at_.....>
Date: Tue Apr 28 2009 - 18:09:23 PDT
My votes below.  Thanks, -Tom

________________________________
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On Behalf Of Mehdi Mohtashemi
Sent: Tuesday, April 28, 2009 4:36 AM
To: sv-ec@eda.org
Subject: [sv-ec] email ballot: response due by 11:00am PDT Friday May 1 2009


We are conducting an email vote on the following issues related

to the p1800-2009 draft 8 LRM Ballot comments.

- Deadline is 11:00am PDT Friday May 1 2009.  This is a shortened

  time voted on sv-ec meeting of April 27 2009, 4 days.

- An issue will pass if there are zero NO votes and half of the

  eligible voters respond with a YES vote.

- A NO vote must be accompanied with a reason.

  The issue will be reviewed at next meeting of sv-ec.

- Note that we are referencing both ballot id and mantis id if

  both exist.  Please read the description of each carefully.

- Mark your vote with an  x.

- Note: There are many items in this email ballot, please review

  carefully.

- Please note if a mantis item is specified and listed below

  along with the ballot comment id it must have a proposal attached

  for vote.



Eligible voters as of April 27 2009 sv-ec meeting are as follows:

17 members.

NOTE: sv-ec voted to include Shalom in the eligible voter list.



Arturo Salz

Cliff Cummings

Dave Rich

Francoise Martinolle

Neil Korpusik

Ray Ryan

Gordon Vreugdenhil

Steven Sharp

Stu Sutherland

Heath Chambers

Don Mills

Jonathan Bromley

Mark Hartoog

Tom Alsop

Mike Mintz

David Scott

Shalom Bresticker





id 48  allow for future enhancement

      _____ YES   _____ No

[Alsop, Thomas R] Abstain,  I wasn't involved in the discussions and I don't see enough information in the spreadsheet to understand what future enhancement is currently being tabled.



id 54  allow for future enhancement

      ___X__ YES   _____ No



id 16, 17

   sv-ec agrees with sv-cc resolution to keep these regions for future use.

   Reject svdb 2632 statement.

   ___ X __ YES   _____ No



id 19  No action required

    ___ X __ YES   _____ No

[Alsop, Thomas R] Assuming that we are keeping the Preponed PLI region in the LRM.  That is my vote, that it doesn't change.



id 20    svdb 2634  (svbc issue)

    sv-ec votes as well to accept the proposal as well.

   ___ X __ YES   _____ No

http://www.eda.org/svdb/view.php?id=2634



id 105 (id 110 is duplicate of 105)

     No action required

    ___ X __ YES   _____ No



id 115  No action required

    _____ YES   __X__ No

[Alsop, Thomas R] This is a small change and makes sense.  I would personally suggest just striking out the '(up to N-1) completely as it's just confusing, however the proposed change is more accurate, although again it does not make sense WRT to the 'M is 3 and N is 3' example that is provided.





id 35, svdb 2705    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2705





ids 36,37,38,39,40

svdb 2700    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2700





id 41, svdb 2681    __X__ YES   _____ No

[both svbc and svec will vote on this]

http://www.eda.org/svdb/view.php?id=2681





id 42, svdb 2682    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2682





id 43 and id 45,

svdb 2430    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2430





id 44, svdb 2701    _____ YES   __X__ No

[both svbc and svec will vote on this]

http://www.eda.org/svdb/view.php?id=2701

[Alsop, Thomas R] I have a lot of issues with the wording and understanding on this proposal for the new sub-clause 7.11.5.

1.       'Tools' should be 'Implementation'.

2.       The third sentence states that "For any such violating operation, a warning shall be issued", but then the next sentence it states "Tools should issue exactly one warning".  In clause 1.5 the conventions for 'shall', 'should', 'may', and 'can' are clear.  I just want to make sure we are being clear in this new sub-clause WRT to these conventions. Seems like the 4th sentence should read that "Implementations shall issue exactly one warning..."

3.       This sentence really confused me "If a violating operation attempts to write more than one element of a bounded queue, any element with index less than or equal to the bound shall be written exactly as it would be if the queue were unbounded." Perhaps an example would help.





id 46, svdb 2706    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2706



id 47, svdb 2713    _____ YES   __X__ No

http://www.eda.org/svdb/view.php?id=2713

[Alsop, Thomas R] Just want to understand why the proposal is using "Error, see text"?  What text?  Is this something the implementations are expected to print out?  Can we just put "Error"?



id 57, svdb 2698    _____ YES   __X__ No

http://www.eda.org/svdb/view.php?id=2698

[Alsop, Thomas R] I am not convinced that 'pure' is required in order to create what is coined a "pure virtual method'.  It's really ambiguous and seems like you can create a prototype virtual method and any level of abstract class hierarchy and only be forced to override it when you extend it to a non-abstract class and hence create the object out of it.  I guess I am asking what the intent behind the 'pure' keyword is?  If an abstract class at any level only prototypes a method, does that mean we have to label it 'pure'.



id 65, svdb 2723    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2723



id 67, svdb 2358    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2358



id 80, svdb 2596    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2596



id 102, svdb 2718    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2718



id 106, svdb 2710    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2710



id 107, svdb 2711    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2711



id 181, svdb 2514    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2035

[Alsop, Thomas R] This should be svdb 2035



id 182, svdb 2514    _____ YES   __X__ No

http://www.eda.org/svdb/view.php?id=2514
[Alsop, Thomas R] I agree with the premise of the proposal, just not with some of the wording as it's not consistent with the draft8 wording.  Specifically the references to 'concrete type' (Clause 8.24, third paragraph on page 142). --> "A generic class is not a type; only a concrete specialization represents a type. In the example above, the class

vector becomes a concrete type only when it has had parameters applied to it, for example"  But this proposal states "A pure constraint represents an obligation on any concrete (non-virtual) derived class", defining a concrete class to a non-virtual class. I'm just unclear about using the wording of 'concrete'.



id 183, svdb 2510    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2510



id 184, svdb 2473

CLOSE 2473,  id 184 requires no further action:

[ Draft8 says

  An associative array type or class shall be illegal as a

  destination type. So this has already been made illegal.]

   __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2473



id 185, svdb 2342    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2342



id 186, svdb 2288    __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=2288



id 192, svdb 1256     __X__ YES   _____ No

http://www.eda.org/svdb/view.php?id=1256





svdb 2719 for the following  ids

id  58  __X__ YES   _____ No

id  60  _____ YES   __X__ No

[Alsop, Thomas R] Is it just me or did we forget the second 'typedef' change to 'type' in the previous sentence?



id  61  __x__ YES   _____ No

id 104  __x__ YES   _____ No

id 108  __x__ YES   _____ No

id 112  __x__ YES   _____ No

id 117  __x__ YES   _____ No

id 118  __x__ YES   _____ No

id 119  __x__ YES   _____ No

id 122  __x__ YES   _____ No

id 137  __x__ YES   _____ No
http://www.eda.org/svdb/view.php?id=2719





--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Apr 28 18:11:57 2009

This archive was generated by hypermail 2.1.8 : Tue Apr 28 2009 - 18:12:40 PDT