The first solution that came to my mind was: local statement (here: super.new(2) ) shall override a general one (here: ... extends B (1) ). This way would be especially usefull if a class could contain more than one constructor. However, SV do not support overloading (in particular: class methods overloading) currently, so there can be only 1:1 relation (inheritance spec. : constructor spec.), and from this point of view: an error message about specifications conflict (" ... extends B (1) " conflicts with "super.new(2)" - only one of them shall be present) is a good solution too. Anyway: is seems like the conflict nature is in C class text entirely, it doesn't matter whether class B has an explicite constructor or not (this could cause another kind of error of course: implicit constructor do not takes a parameter). So, I think: the "... becouse base constructor is already defined" comment do not apply here. Mirek _____ From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On Behalf Of danielm Sent: 9 kwietnia 2008 11:29 To: sv-ec@server.eda.org Subject: [sv-ec] 1800-2005 7.16 Chaining constructors - restriction needed Chapter : 7.16 Chaining constructors :defines that there are 2 possible ways to initialize base class constructor. IMHO there is lack of explicit description what should happened if those both ways are used in the same class. There are two possible solution :it shoul be forbidden. The other possible solution is to define explicitly wich one should take precedence. Cosnidre following example: class B; function new (int i); $display(i); endfunction endclass class C extends B (1); function new; super.new(2);//solution 1: this should trigger error becouse base constructor is already defined endfunction endclass module top; C c=new;//solution 2: this should display 2 and LRM should explicitly defines that super.new takes precedence on extends B(1) endmodule DANiel -- This message has been scanned for viruses and dangerous content by <http://www.mailscanner.info/> MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Apr 9 02:49:35 2008
This archive was generated by hypermail 2.1.8 : Wed Apr 09 2008 - 02:49:45 PDT