RE: [sv-ec] Constant class methods

1.
Maybe there is no time for add both 'const pointer' and 'pointer const' and
const methods in this release of 1800, but for sure this is good moment to
register mantis item on this. 
It is important to may have const handle where you cannot change members not
only as it is in SV today- that only the handle adresss cannot change.


2.
>It must also consider the dynamic nature of the handle itsel
This is not a problem - it could be defined just as any other reference to a
handle - if handle referenced in asssertion is null then it should be fatal
error.

3.
>and the method must be "pure", that is, having no other side effects
And this is also a problem - restriction for using functions in assertions
says:
	"Functions should be automatic (or preserve no state information)
and have no side effects."
This is a problem for compiler to check this rule - it must check called
function and all function called by this function etc.. If there would be
some kind of modifier for regular functions (not only for methods) saying
that function has no side effects (ie const modifier) then it would be much
easier for compiler (performance) to check it.


DANiel 

-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com] 
Sent: Wednesday, April 02, 2008 9:38 PM
To: Mirek Forczek; Rich, Dave; Steven Sharp; sv-ec@eda.org;
danielm@aldec.com.pl
Subject: RE: [sv-ec] Constant class methods

As I wrote before, adding const methods to the language would be a fine
addition. It is, however, an enhancement as this functionality is presently
not a part of the language - there are some things that resembles them:
"const ref" arguments and "const static handles", but these are simply not
the same; simply extending the existing constructs to methods, yields the
semantics derived (correctly IMHO) by Dave Rich.
Note that even C++ has the 'const pointer' and 'pointer const' to
distinguish between the two: an argument that cannot be written and a
reference whose data cannot be written. I don't believe we'll have the time
to sort out all these issues in the allotted time for the 2008 LRM.

Also, a constant method is not sufficient property to allow its use in
temporal assertions. It must also consider the dynamic nature of the handle
itself, and the method must be "pure", that is, having no other side effects
(not only to the objetc's data).

	Arturo 

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Mirek
Forczek
Sent: Wednesday, April 02, 2008 7:17 AM
To: 'Rich, Dave'; 'Steven Sharp'; sv-ec@eda.org; danielm@aldec.com.pl
Subject: RE: [sv-ec] Constant class methods

OK, so let's re-define it:

'this' is a const handle to a dynamic object anyway (as for today),

Applying 'const' on method would imply that 'this' shall be treated as a
const handle to a constant dynamic object - within body range of that
method.

Than you cannot write to class properties of the 'this' object - from within
the const method. 

Mirek
 

-----Original Message-----
From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: 2 kwietnia 2008 16:09
To: Mirek Forczek; Steven Sharp; sv-ec@server.eda.org; danielm@aldec.com.pl
Subject: RE: [sv-ec] Constant class methods

Hold on there. SV does not have static classes. The implicit "this"
argument to a method of a class is just a handle to a dynamic object.
Making "this" a const just prevents you from modifying the handle; you can
still write to class properties.

> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Mirek Forczek
> Sent: Wednesday, April 02, 2008 1:57 AM
> To: 'Steven Sharp'; sv-ec@server.eda.org; danielm@aldec.com.pl
> Subject: RE: [sv-ec] Constant class methods
> 
> Indeed, having 'const' attribute on method would result in treating
the
> implicit 'this' argument as constant one. That's what would happen
within
> scope of the method body.
> 
> But the 'const' attribute on method would have also impact on
semantics
> outside the method body:
> 
> - clearly denote the method's nature (documentation),
> - provide semantics to allow (const) method calls in special contexts 
> (i.e.
> assertion formula),
> - provide input for compiler to enable potential code optimizations.
> 
> Regards,
> Mirek
> 
> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Steven Sharp
> Sent: 2 kwietnia 2008 02:39
> To: sv-ec@server.eda.org; danielm@aldec.com.pl
> Subject: Re: [sv-ec] Constant class methods
> 
> 
> >From: "danielm" <danielm@aldec.com.pl>
> 
> >IMHO SV should itroduce constant modifier to class methods
(functions,
> >and task). This feature is widely used in other languages - ie in
C++.
> >Such modifier should forbid to modify class properties referenced.
> >It would be very usefull to know that certain function do not
modifies
> >the object on which it is called.
> 
> Is this equivalent to treating the implicit 'this' argument as const?
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean.
> 
> 
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean.


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


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