Re: [sv-ec] base interface class references (Mantis 1356)

My opinion is that we should separate the issue since it
impacts existing descriptions and then just applies in the
same manner to 1356. So I'd open a new mantis for that
which can be reviewed/approved separately.

Of course I'm just one member of the committee; other
opinions might differ...

Gord.

On 6/7/2011 1:16 PM, Tipp, Brandon P wrote:
> I don't know what the other issues are. I had assumed that if you want to access any member of a class thru a variable then than that variable can't be null. I've never (intentionally) tried it, but I would have expected a null pointer error.
>
> What text do you want added to where? We can add it to 1356. Just tell me what to add.
>
> -Brandon
>
>
>
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Tuesday, June 07, 2011 12:55 PM
> To: Tipp, Brandon P
> Cc: SV_EC List
> Subject: Re: [sv-ec] base interface class references (Mantis 1356)
>
> I'm not sure why you are requiring that the class handle not be
> null. What is your rationale for that? Other class static variables
> are explicitly permitted to be accessed via a variable containing a null.
> The reasons for not considering the expression as being constant has
> nothing to do with the handle being null, there are other elaboration
> issues that led to that (conservative) restriction.
>
> Gord.
>
> On 6/7/2011 11:29 AM, Tipp, Brandon P wrote:
>> I agree that it's odd behavior that a cast to a superclass (if you can call an interface class a superclass) can provide *more* information than using a variable of the subclass; but I also think that non-virtual methods and hidden variables have an odd behavior where access via a superclass variable provides *different* information than when you use a variable of the subclass type (when there was an override). In this case you must assign to a superclass variable to access a parameter that was not inherited; in the other case you must assign to a superclass variable to access a parameter that was hidden.
>>
>> Would we add this text to the 8.5 (*'s are new)?:
>>
>> The parameter data values of an object can also be accessed by qualifying the class value parameter or local value parameter name with an instance name. *A parameter accessed with an instance name is equivalent to a class scoped reference via the expression type with an additional run-time check that the instance is not null.* Example:
>>
>> class vector #(parameter width = 7);
>> endclass
>> vector #(3) v = new;
>> initial $display (v.width);
>>
>> Such an expression is not a constant expression.
>>
>> Would that be added to 1356, or as a new Mantis item?
>>
>>
>> -----Original Message-----
>> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
>> Sent: Tuesday, June 07, 2011 11:00 AM
>> To: Tipp, Brandon P
>> Cc: SV_EC List
>> Subject: Re: [sv-ec] base interface class references (Mantis 1356)
>>
>> Brandon,
>>
>> I agree with your intent that:
>>
>> but b.p would be legal because that is equivalent to base#(3)::p.
>>
>> But there is no basis for that in the LRM. The LRM does not define "b.p" in
>> that manner so although one can argue that they are in fact equivalent, the
>> LRM does not currently define it as such.
>>
>> The basic issue that I have in this case (and that I don't really like)
>> is that we
>> now have a pretty odd behavior in that casting to a base class (well,
>> an implemented class at any rate) provides *more* information than is
>> accessible via the handle itself. That is a bit odd in terms of LRM
>> regularity
>> and needs to be spelled out.
>>
>> Perhaps the cleanest mechanism would be to redefine parameter references
>> via normal handles to be the same as a class scoped reference via the
>> expression type. That would need to be modified in 8.5.
>>
>> Gord.
>>
>> On 6/7/2011 9:43 AM, Tipp, Brandon P wrote:
>>> Access to a static property of a class from a variable with the . operator is equivalent to accessing that member from the variable's type with the :: operator with an additional check that the variable is not null. That check for null would explain why this statement is in 8.5:
>>>
>>> "Such an expression is not a constant expression."
>>>
>>> Consider the following:
>>>
>>> class vector #(parameter width = 7);
>>> endclass
>>>
>>> class array #(parameter width = 5, height = 7) extends vector #(height);
>>> endclass
>>>
>>> initial begin
>>> array #(5, 3) a = new;
>>> vector #(3) v = a
>>> $display (v.width);
>>> end
>>>
>>> Class properties are never treated as virtual, so v.width will refer to vector#(3)::width, and not array#(5,3)::width. From that perspective, in your second example, der.p would be equivalent to derived::p which is invalid since derived doesn't have a member p, but b.p would be legal because that is equivalent to base#(3)::p.
>>>
>>> Do you think that language needs to be added somewhere to clarify that? What do you want to add and where?
>>>
>>> -Brandon
>>>
>>> -----Original Message-----
>>> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil
>>> Sent: Tuesday, June 07, 2011 8:36 AM
>>> To: SV_EC List
>>> Subject: [sv-ec] base interface class references (Mantis 1356)
>>>
>>> Consider the following:
>>>
>>> class base#(parameter p = 1);
>>> endclass
>>>
>>> class derived extends base#(3);
>>> endclass
>>>
>>> Assume I then have something like:
>>> derived der = new;
>>> base #(3) b = der;
>>>
>>> Per 8.5, it is legal for me to reference "der.p".
>>>
>>> Will the same thing be legal for a interface class?
>>>
>>> interface class base#(parameter p = 1);
>>> endclass
>>>
>>> class derived implements base#(3);
>>> endclass
>>>
>>> derived der = new;
>>> base #(3) b = der;
>>>
>>> Is "b.p" a legal reference here? "derived" definitely
>>> does not inherit (or implement) the parameter "p".
>>> Conceptually, "p" is not part of derived at all, so is it
>>> legal to reference it via a base interface class variable
>>> whose handle is an implementing class? If "b.p" is
>>> legal, is "der.p" legal?
>>>
>>> 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.
>>>
>> --
>> --------------------------------------------------------------------
>> Gordon Vreugdenhil 503-685-0808
>> Model Technology (Mentor Graphics) gordonv@model.com
>>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil 503-685-0808
> Model Technology (Mentor Graphics) gordonv@model.com
>
>

-- 
--------------------------------------------------------------------
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.