Re: [sv-ec] Two simple proposals for discussion

On 21/02/2011 22:11, Jonathan Bromley wrote:
> I've uploaded "draft A" proposals for 3001 and 3293. Please take a look.
As always, something significant occurs to me three minutes after
hitting "send".
> - 3293:
> Tools currently differ in how they handle $cast when the source
> expression is null. I've gone for making that unconditionally a failure.

It's possible this may be entirely the wrong choice. Consider the
OVM/UVM configuration mechanism, which depends on $cast to allow
references to any object derived from an "Eve" base-class (ovm_object)
to be held in a configuration table and later applied to a variable of
the appropriate derived type. Suppose a user actually wants to plant
the value "null" in one of their configured variables? That "null" must
be held in a base-class variable in the table, and later $cast to the
user's derived-class variable. So the library code would need to do an
explicit check for null before attempting the $cast, or at least to take
some complicated evasive action if the $cast fails.

Perhaps, then, it would be better to allow null to go through. But then
what should be done if the source and destination type are on different
branches of the inheritance tree? If so, do we want $cast to fail if
the source is an object, but succeed if it's null? Or do we force tools
into doing a "hypothetical castability" check in the special case of a
null source?

thanks

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