RE: [sv-ec] RE: [sv-bc] Final blocks in packages

Team,

Time for me to chime in a bit here.

While I sympathize with Dave's quest to make the answer be
"It doesn't matter", I think that the barn door is open and
the horses are long gone.

First, we all agree it should be OK to initialize class
variables declared in packages by calling constructors.
Similar for regular variables initialized by VDA's that
include function calls.

Once we permit procedural code to execute at variable init
time, we are wide open to all kinds of side effects.  And
side effects can matter a lot.

So I think we need to answer the question discussed in
the first posting cited by Brad below (4498.html).
My opinion there is that once a package is referenced
in the design, the package is pulled in and all
variable initializations occur.  That way it is possible
to get deterministic side effect behavior across
implementations.

As for not needing destructors, I don't agree with that.
So far the major SV-based methodologies haven't needed them.
But that doesn't mean there are not uses.

In C++ destructors are usually thought of in conjunction with
memory deallocation.  We don't need that in SV, at least.
But there are all kinds of other resources one may wish to
free up.  For example, a class constructor may open a file
handle, and class methods may write to the file.  It would
be nice to have a destructor that could flush and close
the file.  An even better example would be a socket opened
via a DPI call in a constructor, and then closed in the
corresponding destructor.

Regards,
Doug



> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Brad Pierce
> Sent: Friday, May 19, 2006 8:43 AM
> To: sv-ec@server.eda.org
> Subject: Re: [sv-ec] RE: [sv-bc] Final blocks in packages
> 
> "The slippery slope I'm trying to avoid is if a package 
> appears in the woods, and nobody references it, does it still 
> exist? I think the answer to that question should always be 
> it doesn't matter."
> 
> The SV-BC has been discussing that issue, too, for example, 
> 
>             http://www.eda.org/sv-bc/hm/4498.html
> 
> See also the following related question --
> 
>             http://www.eda.org/sv-bc/hm/4530.html
> 
> -- Brad
> 
> 
>