Subject: Re: [sv-ec] Comments on remainder of Chapter 3
From: Michael McNamara (mac@verisity.com)
Date: Mon Jan 06 2003 - 13:38:21 PST
Arturo Salz writes:
> > 3.14 Dynamic casting
> > --------------------
> >
> > Verilog uses have enough problems with static casting, this whole
> > section seems unnecessary. I've seen this sort of programming construct
> > in environments like GUI's where a user may have typed garbage in a
> > field and you are trying to dynamically idiot proof the validation of
> > the form, but I don't see why it is needed in Verilog.
> >
> > Where are dynamic casts needed?
>
> Here's the relevant section of the message I previously sent.
> Arturo
> ----------------------------------------------------------------------
>
> 4. Why is $cast_assign required for assigning a superclass instance
> to a derived class instance - why is this not inherent in
> assignment?
>
> A derived-class can be assigned directly to any of its
> super-classes. However, a super-class can only be assigned to
> a derived class if and only if the sub-class is actually of
> that type. In general, this can only be resolved at run-time,
> thus the need for a dynamic cast. For example:
> class Animal { ... }
> class Mammal extends Animal { ... }
> class Dog extends Mammal { ... }
> class Cat extends Mammal { ... }
>
> Mammal m = new;
> Animal a = m; // correct, mammal is an animal
> Dog d = m; // error: m is not a dog
> Cat c = d; // error: d is a dog not a cat
> $cast_assign( d, m ); // allowed: triggers a run-time error
> if( ! $cast_assign( d, m ) ) begin // user can check at run-time
> d = new;
> end
So this example makes it seem like $cast_assign is analogous to c's
int isalpha(int c) family of routines (see isalpha(2)); the
$cast_assign doesn't do the cast, but instead it returns a value
indicating whether an assign would be legal. Or does executing
$cast_assign(d,m) destroy the current value of d?
I guess what makes sense to me is to follow C's lead and provide a
routine like isalpha, which is purely of an inqury basis, and have the
user then do actual the assignment in the 'normal' way, protected by
the inquiry code. Specifically, is the following the desired coding
style:
Mammal m;
Dog d;
...
m = x; // x is some sort of mammal, arriving from elsewhere.
...
d = find_a_fido(m); // Get a dog, using m if suitable
...
function Dog find_a_fido( m ) begin
// check for dog reuse opportunity
if( can_assign( find_a_fido, m ) ) begin
find_a_fido = m;
else
find_a_fido = new;
end
endfunction //
Justifications:
1) It is my understanding that in the proposal the statement 'm = x';
is still legal; hence introducing this other way to do assigments
(via '$cast_assign(m,x);') which is redundant.
2) it will be non obvious to Verilog users that $cast_assign(d,m) is an
assigment.
3) Orthagonal to whether $cast_assign does the assign, or merely
returns true or false depnding on whether the assign would be legal
is the issue that making this a system task (instead of a builtin
operator) requires us to allow users to provide their own
implementation for $cast_assign, which likely will not do what we
expect.
-mac
This archive was generated by hypermail 2b28 : Mon Jan 06 2003 - 13:39:16 PST