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

Arturo Salz wrote:
[...]

> Since at this point, we seem to agree on what the rules are (please 
> correctly if that is not the case), shouldn't we concentrate on the 
> verbiage that removes any potential ambiguity. I propose the following:
> 
>  
> 
>   The scope for resolution of variable names referenced in the in a 
>   constraint block begins with the randomize()...with object class, i.e., 
>   the class of the object used in the call to randomize. If a name fails 
>   to resolve within the randomize()...with object class, the name is 
>   resolved normally starting in the scope containing the inline constraint.

I still don't like the phrase "class of the object used in the call" because the
type is NOT the class of the *object* it is the class of the reference.

How about:
    The scope for resolution of variable names referenced in a
    constraint block begins with the class type of the reference
    to the "randomize()...with" object. If a name fails
    to resolve within the class of the reference, the name is resolved
    normally starting in the scope containing the inline constraint.


> If this is acceptable, I’ll incorporate it into the proposal. Otherwise, 
> would you please suggest a better alternative.

I don't think "this" is covered yet since "this" is not a member
of the *class* it is an implicit of a non-static method.

So, in addition to the above, how about adding:
    A reference to "this" in the "with" clause shall be treated as
    having the type of the reference to the "randomize()...with"
    object.  A reference to "super" in the "with" clause shall
    be treated in the same manner as a reference to "this.super".


Something along that line should cover things.

I am hesitant to talk about (effectively) replacing "this" by
the object reference which is what Ray was hinting at since
that becomes incorrect in the face of side effect index
expressions in the prefix.  I'm also a bit hesitant to adopt
Steven's approach of talking about a non-static method
equivalence since that only applies to the names that do resolve
into the target object.

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.