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

I have to agree with Gord on this issue. Enforcing pure classes might be
too restricting for many users --- but they are probably a very good
methodology.

Getting back to the previous discussion, I believe the current consensus
is towards restricting the language to allow only "lexically static" or
"locally static" classes. I don't care what we call them as long as we
are clear what we mean and are able to describe it in unambiguous terms
in the LRM. If we decide to go that route then I'd like to take a stab
at what those restrictions might be:

In order for a class to be a legal base class (from which other classes
are derived), the class (and all its super classes) must be lexically
static at the point of extension. This means that the base classes must
be either (a) declared within the scope of the extending class, or (b)
declared in a package. Any other use would be illegal.
Does "lexical locality" affect declaration before use binding? Consider
the example below:

program test;
  typedef class Base;

  int i = 10;

  class Derived extends Base;
     task foo;
        $display(i);
    endtask
  endclass
  
  class Base;
    int i;
  endclass
  
  Derived d = new;

  initial begin
    d.i = 20;
    d.foo();
  end
  
 endprogram

Should this print 10 or 20?
I believe the answer depends on what "lexical locality" means.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Saturday, March 25, 2006 8:12 PM
To: Neil.Korpusik@Sun.com
Cc: francoise martinolle; sv-ec@eda.org
Subject: 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