Subject: RE: [sv-ec] Comments on Chapters 10 and 11 of 3.1/draft 1
From: David W. Smith (david.smith@synopsys.com)
Date: Fri Feb 07 2003 - 11:55:20 PST
In 10.5.2 your suggestion to change
"callee" --> "function declaration"
I do not think is correct. I believe it is actually correct as it stands.
Regards
David
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Brad
Pierce
Sent: Friday, February 07, 2003 8:42 AM
To: sv-ec@eda.org
Subject: [sv-ec] Comments on Chapters 10 and 11 of 3.1/draft 1
10.1 --
"instead of value" --> "instead of by value"
"instead of position" --> "instead of by position"
10.3.2
"Values returned by" --> "In Verilog-2001, values returned by"
Why not just prohibit non-void function calls from being
used as a statement? Yes, C lets you do this, but it's better
to explicitly discard the returned value.
10.5
"arguments ... can be given a ... value" --?-->
"arguments ... can be given ... values"
10.5.1
"provided by Verilog" --> "provided by Verilog-2001"
Why 1094?
10.5.2
Why 1094?
"Not that in the example" --> "Note that in the example"
"callee" --> "function declaration"
10.5.3
"any combination of constants or variables visible at the scope
of the caller and the callee" ????
"The task can the be" --> "The task can then be"
Why don't we always need two commas?
11
This section might read better if it were rewritten without
use of the pronoun 'one'.
11.3
"A class is a collection" ???
Isn't it more a category/type of object?
"A class's data is referred to as properties" ???
A class defines the common properties of a category of object.
11.4
"The last section" --> "The previous section"
11.10
"re-naming" --> "renaming"
There seems to be a contradiction between the comments
in the example task declaration of "test" and the claim
that "This statement has new executing twice, thus creating
two objects, p1 and p2."
11.12
I would omit the final sentence. Most C++ programmers avoid
multiple inheritance, except maybe of abstract base classes
(in the style of Java interfaces).
11.13
"super.super.count is not allowed" ???
Why not?
11.14
"assign subclass" --> "assign a subclass"
In "handle to null", 'null' should be bold.
11.16
"However, for most data (and subroutines) one wants
to hide them from the outside world."
This sentence is oddly phrased.
"other.i" (twice) and "this.i" should be in typewriter font
Why are the defaults of the language the converse of the advice
in the summary? Why isn't 'local' or 'protected'the default?
Why don't we need a special label to make properties and methods public?
11.17
"it can be declared to be abstract by declaring the class to be virtual"
???
Why not declare it 'abstract' then?
Can an abstract class have nonvirtual methods? If not, why do we
need to declare the methods to be virtual? If so, what does it
mean for an abstract class to have a real method?
"Methods of normal classes can also be declared virtual."
Yet there's nothing 'virtual' about them.
Unlike the virtual methods in abstract classes,
they are not just prototypes.
11.18
"super-class" (twice) --> "superclass"
The final sentence could be omitted.
11.20
"called a specialization (or variant)" --> "called a specialization"
11.23
"When an object is not needed anymore" --> "When an object is no longer
needed"
"The automatic memory management system ..."
This and the rest of the section are advocacy
and don't belong in an LRM.
This archive was generated by hypermail 2b28 : Fri Feb 07 2003 - 11:55:56 PST