RE: [sv-ec] "this" and member resolution in inline constraints

I am confused by what the issue is here.

Compile time resolution is always in terms of the statically declared 
fields and methods. Some methods may be declared virtual in the static
class. This means that at compile time you resolve to the virtual
method.
All type checking is done against the virtual method. The actual method
that is called is selected at run time. Data field members are never
virtual. 

In your example the 'x' in the randomize with block resolves to the int
'x' in 
class 'C'. 


-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Tuesday, December 18, 2007 1:50 PM
To: SV_EC List
Subject: [sv-ec] "this" and member resolution in inline constraints


In considering some of the wording for the 1858 (inline constraints name
resolution) issues, I would like to raise an additional concern and/or
need for clarification.

"randomize" is definitely a virtual method.  In the discussion, we were
talking about "this" as following the normal method resolution rules for
"this" references.  That does pose a problem when everything is
composed.

Consider this case:

           class C;
              rand int x;
           endclass
           class D extends C;
              rand bit[1:0] x;
           endclass
           D d = new;
           C c = d;

           initial c.randomize with { x > 0 && x < 10; };

My working assumption has always been that the resolution of "x" is
based on the static type of the object prefix, but I think that the
wording and discussion related to "this" has at least muddied the waters
if not compromised that interpretation completely.

If I have:
          initial c.randomize with { this.x > 0 && this.x < 10; }; the
meaning of "this" is now different.  We would have to interpret "this"
not as the formal of the virtual method "randomize"
but as "a reference to the portion of the object addressable by the
static type of c".

There are many, many issues with a dynamic interpretation of "this" so I
would not want to propose that we follow the dynamic resolution path.  I
believe that the statically typed interpretation I have above is
consistent with Arturo's view.

Since "this" would not follow the normal semantics of a virtual method,
I think that this needs to be reexamined or clarified as part of 1858.

If the more static view of name binding is followed, there are still
potential questions related to handling of other virtual method
references within a constraint and the overall coherency of object
assumptions in such cases.

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.


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