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

In describing (allowing) the usage of 'this' in a randomize with clause,
section 8.10 will also need to be updated. Currently it states:

"The this keyword is used to unambiguously refer to class properties or
methods of the current instance. The this keyword denotes a predefined
object handle that refers to the object that was used to invoke the
subroutine that this is used within. The this keyword shall only be used
within nonstatic class methods; otherwise, an error shall be issued."

I believe what is being suggested is to allow 'this' to also be used
within a randomize 'with' clause (but not std::randomize). Within a
'with' clause, 'this' should denote a predefined object handle that
refers to the object that was the prefix of the randomize method and has
the same (static) type as the prefix. [rather than resolving 'this'
within the object scope - where 'this' doesn't exist]. That is:
	c.randomize() with { this.x > 0; }
is equivalent to:
	c.randomize() with { c.x > 0; }


-Ray

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Vreugdenhil, Gordon
> Sent: Wednesday, December 19, 2007 7:00 AM
> To: Mark Hartoog
> Cc: SV_EC List
> Subject: Re: [sv-ec] "this" and member resolution in inline 
> constraints
> 
> 
> 
> Mark Hartoog wrote:
> > I am confused by what the issue is here.
> 
> It is clarity of the text for the non-implementor.
> 
> > 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'.
> 
> 
> Sure, you and I and other implementors know that.  I'm 
> certainly not suggesting any other binding.
> 
> 
> What the text doesn't say is:
>    1) that the inline constraint is effectively its own non-virtual
>       method rather than being "part of" randomize.  Without
>       such a statement the only "this" that a reader could assume is
>       the "this" of the randomize method that is *actually called*.
>       That type is not known.
>    2) that the class in which the "method" lives is the class
>       defined by the type of the reference
> 
> The current approved 1858 text talks about "the 
> randomize...with object"
> and NOT the type of the reference.  That could easily lead 
> readers to assume the highly dynamic behavior.
> 
> By the way, you certainly cannot tell the type of the class 
> reference at compile time -- if the prefix is a general 
> hierarchical reference or similar then you can't possibly 
> know until elaboration time.  So where the names bind is 
> certainly an elaboration time decision based on the static 
> type of the reference; the non-virtual method model is just a 
> convenient way to talk about the effect.
> 
> Gord.
> 
> 
> > 
> > 
> > -----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
> > 
> > 
> 
> --
> --------------------------------------------------------------------
> 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.