Re: [sv-bc] E-mail Vote: Respond by Monday, May 11, 2009 8am PDT

From: Steven Sharp <sharp_at_.....>
Date: Fri May 08 2009 - 16:34:05 PDT
>SVDB 1651 ___Yes   _X_No
>http://www.eda.org/svdb/view.php?id=1651

My reasons are the same that Gordon gave, but are enough to tilt my
vote to No.  I have some additional comments on the "legacy" issue.

When the committee adopts a feature similar to a non-standard extension,
it must be free to fix any problems in that feature (such as a poorly
chosen name).  Vendors should be aware of this risk when they provide
non-standard extensions, especially if they do not present them to the
standards committee for review before promoting them.  Users should be
aware of this risk when using non-standard features, and put pressure on
their vendors to bring them to the standards committee.  If the committee
accepts this as a "legacy" issue, then they remove an incentive for
vendors to design their extensions well and bring them to the committee
early.  Instead, it creates an incentive for vendors to defer bringing
their extensions to the committee until they have been used long enough
for them to claim a "legacy" issue.  This is not desirable.

The committee did not make this existing code any less standard than it
was when it was written.  Also, the standard name of $sformatf was
approved by the committee 2 years ago, so the risk of using this non-
standard feature should have become more obvious after that point.


>SVDB 1791 _X_Yes   ___No
>http://www.eda.org/svdb/view.php?id=2791
>
>SVDB 2501 _X_Yes   ___No
>http://www.eda.org/svdb/view.php?id=2501
>
>SVDB 2568 _X_Yes   ___No
>http://www.eda.org/svdb/view.php?id=2568
>
>SVDB 2593 _X_Yes   ___No
>http://www.eda.org/svdb/view.php?id=2593
>
>SVDB 2611 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2611

Abstaining, because I have not studied the text enough to fully understand
whether this resolves it properly.

>SVDB 2674 _X_Yes   ___No
>http://www.eda.org/svdb/view.php?id=2674
>
>SVDB 2678 ___Yes   _X_No
>http://www.eda.org/svdb/view.php?id=2678

I don't think the proposal is clear enough about whether the name is
printed escaped if it did not need to be escaped.  Note that even if
such a name is specified escaped in the declaration, the name is the
same as if it were not escaped there.  It can be referenced with a
nonescaped name elsewhere.  Other situations such as %m do not print
the name escaped if it does not need it.  So I don't think it should be
printed escaped if it does not need it.

>SVDB 2681 _X_Yes   ___No
>http://www.eda.org/svdb/view.php?id=2681
>
>SVDB 2721 _X_Yes   ___No
>http://www.eda.org/svdb/view.php?id=2721
>
>The following Mantis items are proposed to be resolved as:
>
>"The committee read and considered this feedback. the committee believes it
>is too broad for the scope of the draft to implement at this time but may
>be considered for future revisions."
>
>SVDB 2580 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2580
>
>SVDB 2669 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2669
>
>SVDB 2671 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2671
>
>SVDB 2673 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2673
>
>SVDB 2679 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2679
>
>SVDB 2684 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2684
>
>SVDB 2686 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2686
>
>SVDB 2687 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2687
>
>SVDB 2688 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2688
>
>SVDB 2689 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2689
>
>SVDB 2690 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2690
>
>SVDB 2691 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2691
>
>SVDB 2697 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2697
>
>SVDB 2720 ___Yes   ___No
>http://www.eda.org/svdb/view.php?id=2720
>
>-- 
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>
>

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri May 8 16:34:49 2009

This archive was generated by hypermail 2.1.8 : Fri May 08 2009 - 16:35:37 PDT