RE: [sv-ec] initializing class properties

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Tue Jan 22 2008 - 18:46:08 PST
<forwarding bounced email from Arturo Salz>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


attached mail follows:


Yes. It is forbidden. See the last sentence in the 1st paragraph of
section 8.10 (2008 LRM):

 

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.

 

   Arturo

 

________________________________

From: danielm [mailto:danielm@aldec.com.pl] 
Sent: Monday, January 21, 2008 1:17 AM
To: 'Arturo Salz'; sv-ec@eda.org
Subject: RE: [sv-ec] initializing class properties

 

Well - now I see that LRM allows declaration initialization for class
properties - but IMHO this is a mistake to allow such code - and it
should be forbidden by the language - the reasons are given in prev
email. There is nothing but the mess & confusion what we may gain from
allowing above.

 

I believe using "this" in the declaration is illegal - "this" is only
visible within non-static methods. Otherwise, your example:

Where is it forbidden? Is it forbidden?

 

 

 

DANiel

 

 

________________________________

From: Arturo Salz [mailto:Arturo.Salz@synopsys.com] 
Sent: Saturday, January 19, 2008 12:07 AM
To: danielm; sv-ec@eda.org
Subject: RE: [sv-ec] initializing class properties

Daniel,

 

The semantics of such initializers are discussed in page 85 of 2005 LRM
(see second sentence below):

 

The new operation is defined as a function with no return type, and like
any other function, it must be non-blocking. Even though new does not
specify a return type, the left-hand side of the assignment determines
the return type.

 

Class properties that include an initializer in their declaration are
initialized before the execution of the user-defined class constructor.
Thus, initializer values can be overridden by the class constructor.

 

I believe using "this" in the declaration is illegal - "this" is only
visible within non-static methods. Otherwise, your example:

 

class A ;

    int i = 5;

    int j = i;

    A a = this;

endclass

 

is equivalent (and correct) to:

 

class A ;

    int i;

    int j;

    A a;

    function new();

      i = 5;

      j = i;

      a = this;   // this seems weird, but valid nonetheless

    endfunction

endclass

 

   Arturo

 

________________________________

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
danielm
Sent: Friday, January 18, 2008 7:00 AM
To: sv-ec@eda.org
Subject: [sv-ec] initializing class properties

 

I haven't found an explicit LRM saying if class properties can be
initialized but LRM uses examples like:

class A ;

integer j = 5;

endclass

Is it allowed  somwhere in LRM or this is just a mistake?

 

IMHO allowing such code is problematic. Other mature languages like ie
C++ do not allowed such initialization. In fact 'j' is dynamic doesn't
exist at the moment when it is initialized - because of that the
contructor is proper place for variable initializations. 'j is created
when object is created by constructor. Initialization is a reason why
the constructor was introduced into the language.

 

Allowing class properties to be initialized iallows not only such simple
examples as above but also more complicated cases where we initialize
non existing variable with other non existing  varialbe:

class A ;

    int i = 5;

    int j = i;

    A a = this;

endclass

 

All above is not neat coding sample - why LRM does not explicitly
forbids such codes.

 

DANiel


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jan 22 18:46:42 2008

This archive was generated by hypermail 2.1.8 : Tue Jan 22 2008 - 18:47:04 PST