RE: [sv-ec] are constraints virtual like?

Arturo,

I agree that constraints act as if they were virtual when used by a
randomize call. This works because randomize() is virtual, and the
constraints are accessed by randomize(). Since randomize() is virtual,
you will call the one for the actual object type. And that randomize()
will access the constraints that are visible in that object type.

But Daniel's question was actually about calling constraint_mode. It
does not appear to me that this will act in a virtual fashion.

First of all, the LRM does not say that constraint_mode is virtual.
Note that it explicitly states that randomize() is a virtual method,
and the pseudo-prototype for randomize() has the virtual qualifier.
It does not state that constraint_mode is virtual, and the pseudo-
prototype for constraint_mode does not have the virtual qualifier.

Second, I don't think that it would matter if the LRM made constraint_mode
virtual anyway, given the syntax and the conceptual model. The syntax is
handle.constraint.constraint_mode(). Conceptually, a member select is
applied to the handle to select a constraint, and then the constraint_mode
method is called on that. By the time the method is called, a particular
constraint has been selected using the member select, which will use the
type of the class handle, not the class object. Once that particular
constraint has been selected, you are committed, before the method is
called.

The form where constraint_mode is called on the entire object, with the
syntax handle.constraint_mode(), could be treated as virtual. In that
case the method is being called directly on the class handle. So you
could have that affect the constraints in the actual object type. But
then this would be inconsistent with the other form. It would be confusing
if calling handle.constraint_mode() were not equivalent to calling
handle.constraint.constraint_mode() for each constraint in the object.

To get a virtual mechanism for constraint_mode(), you would need to have
the member select of the constraint itself be virtual, so that the constraint
was selected based on the actual object type, before the method was called.
There is nothing in the LRM to indicate that this is the case.

The situation is similar for rand_mode(). You have the syntax
handle.variable.rand_mode(). Again, this is a member select followed by
a built-in method call. So the variable has already been selected based
on the handle type, before the method is called. For member selects that
select a property, we definitely know that the select is not virtual.

So I think the answer to Daniel's question is that constraints are not
virtual. When they are accessed from randomize(), which is virtual, it
doesn't matter that they aren't virtual. You get the same behavior anyway.
But when they are accessed with a member select from a handle, so that
you can then apply the constraint_mode() method to them, you do not get
virtual behavior.

You can create a virtual mechanism by writing your own virtual methods,
one for each constraint, which calls constraint_mode() on that constraint.

Steven Sharp | Architect | Cadence

P: 508.459.1436 M: 774.535.4149 www.cadence.com

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