RE: [sv-ec] email ballot: response due by 1:00pm PDT Wednesday May 13 2009

Here are my votes.

      Arturo




  mantis 2700   proposal 2700-2.pdf for

   the two following ids.

id  37  __X__ YES   _____ No

id  38  __X__ YES   _____ No

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



  mantis 2575 proposal  err_2575.pdf

   for the following  ids

id  50  _____ YES   __X__ No

id  52  _____ YES   __X__ No

id  59  _____ YES   __X__ No

id  64  _____ YES   __X__ No

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



I would like to normalize access to all parameters via the class resolution operator only. If pushed, I would agree to allow this.value_parameter only because the unadorned form is also allowed.

I agree with the intent of Id-64 (use the class resolution operator to access type parameters) but the current proposal should be merged with the proposal of Mantis 2575, to includes the extra verbiage and the examples - possibly a type parameter example.



id 182, svdb 2514    __X__ YES   _____ No

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



id 183, svdb 2510    __X__ YES   _____ No

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



I have some reservation as to the resulting clarity since it is not immediately apparent from the reference section (6.21) which are the variables restricted to procedural blocks (it is a the very end), but I don't feel strongly enough about this to vote no.



id 185, svdb 2342    _____ YES   __X__ No

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



I only object to the limitation that the constructor may not be static -why not? And, would there be a semantically observable difference between a static versus a non-static constructor? I don't believe there is such a difference. I will change my vote to yes if that limitation is removed.



id 186, svdb 2288    __X__ YES   _____ No

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






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