Tom, a few detailed comments on proposed changes below.
In terms of the 16-18 issues, I thought that my detailed
comments from the committee discussion addressed most of your
earlier questions.
In particular, yes, there would be an enforced "cut-and-paste"
type of prototype duplication with abstract classes implementing
interface classes. There were several people on the committee
that believed that such duplication is in fact good as it brings
the requirements "closer" to the implementing class hierarchy
and makes future obligations from the abstract class to its
descendents become clear and in one location rather than inferred
from the interface classes. If you disagree, we can discuss that
in the next meeting.
One additional comment that you made was of concern:
*/ if you wanted to _explicitly override the base method to be
virtual_. /*
You can never change a base method to become virtual. Not with
regular inheritance (and I don't want that to be part of implements).
If an extended class overrides a non-virtual method in a base class
with a virtual prototype, that new virtual prototype *hides* the
base method, it does not coerce the base method into a becoming
virtual.
Detailed comments on the rest:
On 8/3/2011 5:11 PM, Alsop, Thomas R wrote:
> [...]
>
> 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. *
>
I think that I'd prefer something like:
**It shall also be legal to cast from an object handle to an interface
class type handle if the actual object implements the interface
class type.
That is closer to the $cast wording and avoids a new term
"implemented object".
> 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). *"*
>
I'm fine with adding "only" but I'd prefer to make this
even stronger by adding the explicit restriction that:
It shall not be legal to access interface class parameters
or localparams through an interface class select (a
dotted reference).
[...]
*> 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?*
>
How about something like the following:
A randomize method call shall be legal with interface class handles.
While inline constraints shall also be legal, interface classes
cannot contain any data meaning that inline constraints will only
be able to
express conditions related to state variables and are therefore
of very limited utility. Use of rand_mode and constraint_mode
shall not be legal as a consequence of the name resolution rules
and the fact that interface classes are not permitted to contain data
members.
> 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?*
>
That would be my preference. If anyone else disagrees
I hope they speak up.
> 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.
>
Yes.
> 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.
>
Yes.
Gord.
-- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Aug 4 07:32:10 2011
This archive was generated by hypermail 2.1.8 : Thu Aug 04 2011 - 07:32:20 PDT