>From: Arturo Salz <Arturo.Salz@synopsys.com> >I'm not sure that allowing explicitly declared static constructors would enable (or their lack disable) the forms you envision. The truth is that constructor are already somewhat like static methods - they are not called using a handle. They are not invoked using a handle because their invocation allocates the object that they use. But regardless of how they are invoked, they are inherently not static. Their purpose is to construct the object, which they cannot do without access to the object. They have to be passed a 'this' handle (which is the handle for the allocated object) so that they can initialize the nonstatic members of the object. I suppose you *could* allow a static new() that performed a variety of side-effect operations you wanted to do any time an object of that type was allocated, where none of the operations required access to any of the nonstatic properties. For example, it might update a count of the total number of allocations of objects of this type in a static property. In a derived class, any super class constructor would have to be static also, since it is called from this constructor. Since I think that any initializers attached to nonstatic properties should be executed by the constructor immediately after the super.new call, I also wouldn't allow any initializers in this case either. So this would only work if you were willing to accept the default initial values for all nonstatic properties of the class. This seems pretty useless. Whether you allow invoking the constructor with a class:: syntax should be independent of whether the constructor was declared static or not. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu May 7 17:27:22 2009
This archive was generated by hypermail 2.1.8 : Thu May 07 2009 - 17:28:04 PDT