{Disarmed} [sv-ec] Additional 1356 review (interface classes)

Full response to Gord's email. Huge thanks Gord!! Still waiting for your response to the last email I sent out.

FYI, that I am on vacation starting next Monday for two weeks. Brandon can take over if we need more edits.

-Tom

1) 8.25.5.1 -- example has "function function".
talsop> FIXED

2) 8.3 Grammar error.
       [implements
                interface_class_type [ ( list_of_arguments ) ]
             {, interface_class_type [ ( list_of_arguments ) ] } ]
   Should be:
       [implements
                interface_class_type {, interface_class_type } ]

   The list_of_arguments (in the extends part of the production)
   is related to the constructor call. Interface classes don't
   have constructors.
talsop> FIXED

3) 8.25.1 Same grammar issue

        [ extends interface_class_type [ ( list_of_arguments ) ]
               {, interface_class_type [ ( list_of_arguments ) ] }]
   Should be:
        [ extends interface_class_type {, interface_class_type }]
talsop> FIXED

4) 8.25.3.1 Should also restrict implements from interface based types.
talsop> This is explained in 8.25.2:

 * An interface class
    * may extend zero or more interface classes
    * may not implement an interface class
    * may not extend a class or virtual class
    * may not implement a class or virtual class

5) The proposed re-wording for 8.15 ($cast) isn't quite right.
    It wouldn't allow a cast from an interface class type expression
    to a class type target (since the interface class could not
    possibly be a superclass of the class). I think that we could
    change the rewording of the second bullet to just:
        o the type of the source expression is an interface class
talsop> CHANGED to your version.

6) 8.25.4 Change the sentence:
        It shall be legal to assign an object handle to a variable
        of an interface class type that it implements.
    to:
        It shall be legal to assign an object handle to a variable
        of an interface class type that the object implements.
talsop> DONE

7) 8.25.4 "It shall also be legal to have multiple references of
    an interface class and use them to cast from one to another."

    This is potentially confusing -- you never have objects of an
    interface class type, only variables of those types. So how about:
    "It shall be legal to dynamically cast between interface class
    variables if the actual class handle is valid to assign to the
    destination."
talsop> Agreed. Changed to your wording.

8) 8.25.4 What is a "prototype interface class handles"? More
    generally, the entire sentence "It shall also be legal to
    cast implemented objects onto their prototype interface class
    handles" is not careful enough about object and type
    distinction. See comment 8.
talsop> I think we meant to say this "It shall also be legal to cast implemented objects to a variable of an interface class type that the object implements"
talsop> So I updated with this change.

9) It is legal to access parameters in an interface class
    as "IntfClass::param_name". Is it legal to have:
        IntfClass ic = some_object;
        int x = ic.param_name;
    In other words, are static data members (such as parameters)
    accessible as a select from a variable of an interface
    class type?

Notes: While it is likely that there are no substantive issues
    in allowing dotted parameter name references, it was the
    committee consensus that we are likely better off to
    make such references illegal for now in order to reduce
    potential confusion for users. The "::" qualified reference
    makes it more clear that this parameter is related to the
    *type* of the reference, not to the object. Since
    interface class variables cannot have other non-method dotted
    refereces (since there are no other data members), it seems
    more reasonable for the time-being to keep interface class
    parameter references closely couple to the type and require
    a "::" reference.

talsop> I thought we made this abundantly clear in 8.25.3, second sentence... "All parameters and typedefs within an interface class are implicitly static and can be accessed through the class scope resolution operator :: (see 8.22). " Perhaps we can clarify this further by saying "All parameters and typedefs within an interface class are implicitly static and can only be accessed through the class scope resolution operator :: (see 8.22). "

10) Syntax in 8.3:
        interface_class_type :: ps_class_identifier[parameter_value_assignment]
    should be:
        interface_class_type ::= ps_class_identifier[parameter_value_assignment]
                             ^^^
talsop> I hate missing stupid little things like that. Okay, FIXED.

11) Syntax at the end of 8.25.1:
        interface_class_method ::= pure virtual method_prototype
    "pure" and "virtual" should be bold.

talsop> FIXED.

12) 8.25.2 The sentence:
        Conceptually an extends is considered a means to extend the
        content of the a superclass...
    is awkward. How about:
        Conceptually an extends clause is a mechanism to add to
        or modify the behavior to a superclass...

talsop> I changed this to "Conceptually extends is a mechanism to add to or modify the behavior of a superclass...", I have never heard of constructs being called a clause.

13) 8.25.2
        Because virtual classes are abstract they may or may not fully
        define ..
    How about:
        Because virtual classes are abstract they are not required to
        fully define ..
talsop> CHANGED.

14) 8.25.5.1 In the first example, I think I disagree with the
    requirement to have funcBase be defined in ClassExt. Doesn't
    that requirement conflict with the example in 8.25.2? I do
    agree with the second example and the examples in 8.25.5.2
    and 8.25.5.3.

Notes: Gord -- I think this was a hold-over from an earlier
    review. You can ignore this one.
talsop> Whew, because it looked okay to me.

15) 8.25.5.3. The sentence:
        Each unique parameterization of a parameterized class is a
        unique class. Therefore, it shall be a conflict if a
        parameterized class is...
    should be:
        Each unique parameterization of a parameterized interface
        class is a unique interface class. Therefore, it shall be
        a conflict if a parameterized interface class is...
talsop> FIXED.

16) Can a handle to an abstract base class be used as a reference
    to an implemented method even if the method is not directly
    declared? So is the following legal:

        interface class intf;
            pure virtual function void f();
        endclass
        virtual class base implements intf;
        endclass
           //...
        base b = some_valid_object_derived_from_base;
        b.f(); // <<<< is this legal?

    It is not clear from the proposal that this is legal although
    my expectation from committee discusion is that people would
    like it to be.

    We should carefully consider that choice. Allowing
    "base" to essentially inherit the pure function prototype
    weakens the distinction between "extends" and "implements"
    and also may pose later surprises if "base" doesn't
    implement everything. By requiring "base" to have all
    needed prototypes, one gets a clear picture at the point
   of the implements of what obligations may still be outstanding
    in the type hierarchy derived from base. So I'd prefer to
    require "base" to prototype all implemented methods or,
    at least, to disallow calls from "base" to an unprototyped
    implemented method.
talsop> Addressed in separate email thread.

17) Does the user need to explicitly indicate "virtual" on the
    first implementing definition or is that implied by the implements
    in the same way as it would be during inheritance?
        interface class intf;
            pure virtual function void f();
        endclass
        class base implements intf;
            function void f(); endfunction
        endclass
talsop> Addressed in separate email thread.

18) The question of whether a pure virtual hides a non-virtual is
    still open. So is the following legal:
        class base;
            function void f(); endfunction
        endclass
        interface class intf;
            pure virtual function void f();
        endclass
        virtual class der extends base implements intf;
        endclass
        class der2 extends der;
            function void f(); endfuntion
        endclass
    If you have:
        der d = some_legal_obj;
        d.f();
    what is called?
talsop> Addressed in separate email thread.

19) Can one call randomize() via an interface class handle?
    Certainly on cannot use inline constraints, rand_mode or
    constraint_mode (which should be noted in the LRM).

Notes: The consensus was the randomize should be legal.
    The conceptual view is that all classes (by LRM
    definition) provide a virtual randomize method. So
    by considering any interface class to implicitly
    have a requirement for such a method, all classes
    can satisfy that requirement (by definition). We
    did not want to get into that kind of rationale
    in the text however; we believe that it is sufficient
    to note that randomize is legal. There should be
    commentary that while inline constraints, rand_mode
    and constraint_mode are "legal", by definition of
    how name resolution is done, they can't address any
    data members via an interface class reference since
    interface classes have no data members.
talsop> I added this under section 8.25.9 after changing the clause heading:

8.25.9 Constraint Blocks, Cover Groups, and Randomization

Constraint blocks and cover groups shall not be allowed in interface classes.

Randomization shall be legal on interface class handles, however the method will not address any data members of the interface class as the interface class has no data members.

talsop> Is this what is needed? Do we want to clarify when randomize would actually be applicable, like in implemented class object that are assigned to the handle?

20) What does $bits return for an interface class handle? How
    does this relate to streaming operators? Can one stream
    from/into an interface class handle? 11.4.14.1 needs to
    define streaming behavior for interface class handles.

Notes: The current status of $bits and streaming for classes
    is pretty bad already. There was at least weak
    consensus that we should make these illegal in this
    PAR for references through interface class variables.
    Trying to define something rational here is likely
    to require substantial work in the core existing
    definitions.

    We were out of time on this one so if anyone disagrees
    with my understanding of the agreement, please say so.
talsop> Do I need to add a statement at the end of this clause declaring the use of $bits() on interface class handles illegal?

21) 21.2.1.7 should permit interface class handles as well.
talsop> So do we change this:

A chandle, class handle, event, or virtual interface shall print its value in an implementation dependent
format, except that a null handle value shall print the word null.

to this:

A chandle, class handle, interface class handle, event, or virtual interface shall print its value in an implementation dependent
format, except that a null handle value shall print the word null.

22) 6.22.5 should include interface class
talsop> So do we change this:

6.22.5 Type incompatible
Type incompatible includes all the remaining nonequivalent types that have no defined implicit or explicit
casting rules. Class handles and chandles are type incompatible with all other types.

to this:

6.22.5 Type incompatible
Type incompatible includes all the remaining nonequivalent types that have no defined implicit or explicit
casting rules. Class handles, interface class handles, and chandles are type incompatible with all other types.
________________________________

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