Open tudortimi opened 5 years ago
I guess you'd want to keep extends as the default due to backwards compatibility reasons. I would argue that the main use case should be to mock interface classes, but I'm also pretty sure that most users are mocking concrete or abstract classes. I wouldn't mind having either an extra macro for this (_SVMOCKINTF) or the possibility to specify the default connective as a macro:
`define SVMOCK(NAME, PARENT, CONNECTIVE = `SVMOCK_DEFAULT_CONNECTIVE) \
class NAME CONNECTIVE PARENT; \
// ...
`define SVMOCK_DEFAULT_CONNECTIVE extends
This way it's possible to set the default connective like so:
`include "svmock_defines.svh"
`define SVMOCK_DEFAULT_CONNECTIVE implements
// ...
Any thoughts on implementing this feature?
@muneebullashariff A workaround for this is to define a dummy class that extends the interface to mock. Due to the fact that the IEEE people believe strongly in boilerplate code, you're also going to have to re-declare all interface method in that dummy class:
interface class some_intf;
pure virtual function void some_func();
pure virtual function void some_other_func();
endclass
virtual class some_intf_dummy implements some_intf;
pure virtual function void some_func();
pure virtual function void some_other_func();
endclass
`SVMOCK(some_intf_dummy)
Since the SVMOCK macro uses extends to define the mock class, we can't use it to mock an interface class. The easiest way I can think of is to provide the 'extends/implements' construct as a third argument.