Re: [sv-ec] question about name resolution in classes

Francoise,

This is an area that is quite a bit more interesting than
even your example.

The basic question is how to align lexical (and package)
search rules with class member and property lookup.

In the package case (such as yours), since the package is
required to exist, the resolution of the base type
is required to be known, so I think the intuitive answer
is that "i" is the member reference and needs to be
resolved as such.  It isn't clear to me however that this is
going  to end up being the answer.

There are other contexts which are far more difficult since
there are separate compilation issues that come into play.

Consider:

    module child;
       parameter type T = int;

       int i;
       class derived extends T;
           function void dump;
               $display(i);
           endfunction
       endclass
    endmodule

    package p;
       class base;
           bit b;
       endclass
    endpackage

    module top;
       class base;
          int i;
       endclas

       child #(base) c1();
       child #(p::base) c2();
    endmodule

In this scenario, what does "i" mean in class
derived?  You can't possibly know what it is
or whether it is even lexically resolved to child.i
or resolved in the context of the class hierarchy.
In my example, the answer changes in the different
module instances.

Since module child is a valid module for separate
compilation there is no way to determine the answer
at compilation; elaboration time is the earliest at
which this can be resolved.

This is complicated by the package import rules.
If you didn't have "i" declared in "child" but it was
potentially visible, would you do the import and make
it actually visible?

One reasonable approach to the general problem is
to require a "this." or "super." prefix for references
to inherited members in at least some situations.

I don't think there is any ideal solution to the naming
issue since you either have to deal with syntax
requirements or have to try to define some reasonable
rules for when an implementation is required to know
things about the inheritance structure and when the
user is required to disambiguate.

This is loosely related to the issues with randomize()
that Ray and I have been working on a proposal to
address.

Gord.


francoise martinolle wrote:
> Supposed I have a base class in a package and I create a derived class 
> of that class in a
> module. I do not import the package but I use the package scope syntax 
> to indicate
> the base class. Does this cause all the class item declaration of the 
> BASE class to be
> visible in the derived class?
>  
> I think it should.
>  
>  
> package p;
> class BASE;
>   rand logic i;
> endclass
> endpackage
>  
>  
> module top;
> class derived extends p::BASE;
>        constraint c1 { i == 1'b1};
> endclass
> endmodule
>  

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com