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

Neil,

I don't think that your example was a terribly accurate
representation of the SV example that I gave.  In particular,
the C++ example is accessing a function local rather than
a "module" or "package" declaration.

A closer C++ example (which compiles and runs cleanly) is:

    int j;
    #include <iostream>
    int main() {
       static int i;
       class c {
       public:
          void geti() {
             printf("i=%0d j =%0d\n", i,j);
          }
       };
       c  c1;
       i = 69;
       j = 70;
       c1.geti();
    }

"main" is nothing more than a function in C++; I wouldn't have any
objection to the restrictions that you suggest within
functions if we were even allowing class type declarations in
functions (which we don't since class declarations are only module,
generate, package, or program items).

Having class access non-local (C++ static) declarations or,
package declarations in other languages, is pretty well
established practice and it would likely be pretty surprising
to have SV objects be required to be "pure" objects.

On a philosophical basis, I might prefer the cleaner model,
but there are reasonable arguments for not having such
restrictions.

I doubt that the restriction that you are suggesting would be
acceptable in the overall user community.

Gord



Neil Korpusik wrote:
> The notion of class methods being able to directly access variables that are
> declared outside of the class goes against the grain of object-oriented
> programming (OOP). It is my opinion that class methods should only be able to
> access class properties or arguments that are passed to the method. This is
> consistent with C++.
> 
> One of the concepts of OOP is data encapsulation. Allowing class methods to
> reach outside of the class to access variables declared in a module or program
> breaks the concept of data encapsulation. Accessing variables in this way
> creates the equivalent of a global variable which is shared by all instances of
> the class.
> 
> At a minimum, this type of variable access is a very poor programming style.
> It allows inadvertent access to variables outside of the class when the
> intent was to use a class property. This could be a difficult bug to find.
> 
> The following is not a valid C++ program. The C++ compiler complains with
> "The name i is unusable in c::geti()."
> 
>    #include <iostream>
>    int main() {
>       int i;
>    class c {
>    public:
>       void geti() {
>          printf("i=%0d\n", i);  <-- C++ compiler complains
>       }
>    };
>       c  c1;
>       i = 69;
>       c1.geti();
>    }
> 
> 
> 
> Gordon Vreugdenhil wrote On 03/23/06 22:27,:
> 
>>Fancoise,
>>
>>I'd like to make sure that I understand your thinking here -- I
>>think that you are suggesting that normal lexical and
>>package name binding should occur *before* class hierarchical
>>resolution, is that correct?
>>
>>In particular, given a simpler example of my example:
>>
>>    module child;
>>       int i;
>>       class base;
>>           int i;
>>       endclass
>>       class derived extends base;
>>           function void dump;
>>               $display(i);
>>           endfunction
>>       endclass
>>    endmodule
>>
>>your view would be that the reference to "i" inside
>>derived::dump would refer to child.i and not to
>>the property in base.  If the user wanted to refer
>>to the property in base, they would have to use
>>super.i (or possibly this.i).  Is that a correct
>>understanding of your description?
>>
>>Gord

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