[sv-ec] Comments on Chapters 10 and 11 of 3.1/draft 1


Subject: [sv-ec] Comments on Chapters 10 and 11 of 3.1/draft 1
From: Brad Pierce (Brad.Pierce@synopsys.com)
Date: Fri Feb 07 2003 - 08:41:50 PST


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 - 08:43:48 PST