Re: parent_ctor()

Zeev Suraski wrote: > (Most) Web projects have, and IMO, will always have one major difference > from other applications - they are *realtime*, or in other words, they must > be fast. ^ enough > PHP, as a Web language, isn't likely to benefit > from an advanced and less dynamic OO model. I'm not saying that it won't > benefit at all - perhaps Kristian would find it indispensable for PHPlib, > but the vast majority of Web developers would not. I am not arguing for a less dynamic OO model, in fact I am in great favor of any model which delays as many decisions as possible as long as possible, in order to facilitate a component oriented design. The _only_ place where I argued that less dynamism may be useful is when it comes to instance variables. I argued that they do not buy you anything, since $o->$somevar can easily be written as $o->myhash[$somevar] without any loss of functionality (in fact you gain functionality, specifically the ability to use all standard array functions on $o->myhash[], which wasn't possible with $o->$somevar). Limiting object do class-predeclard instance variables may speed PHP - I haven't had a look at the implementation at all, and in any case it will make it easier to spot coding errors. What I am arguing, and vehemently, is that PHP should get some object model at all. Because what PHP currently uses under the name of objects and classes is something grown, and grown out of some midnight hack. For that it is amazingly powerful, but it has a number of limitations, and it has been extended in a quite uncontrolled manner (e.g. the constructor mess). At the moment this is just sad, but it may become probematic in the future, because with the added speed and functionality of the language, PHP applications will become larger and more complex. PHP is nice as a language to hack up some semi-interactive webpages quickly, but unlike PHP/FI it is no longer limited to this. With PHP3 it became a platform for the development of small and medium sized web applications (and PHPLIB did its little part to help PHP on this way), and that is already vastly beyond anything PHP/FI could dream of. It will not stop here: with PHP4, the compiler, cache and optimizer it will go _much_ further into the realm of web applications and transaction handling. PHP4 will get an XML/XSLT processor instead of a simple template system. It will run as a coprocess to one or multiple webservers and will be called by stub functions shipping parameters with ONC RPC, DCE RPC, WDDX, Corba calls or SOAP to and from the PHP application coprocess. And it will do SSL and TLS natively. Perhaps somebody will even interface PHP with a transaction monitor. In any case people will write PHP extensions in C and PHP libraries in PHP to access all these features. PHP desparately needs a mechanism to handle all this functionality without increasing usage complexity beyond what can be handled by the average developer. The current mechanism to do this is the PHP object system, and it must grow accordingly in functionality to accomodate the growth of PHP and PHP application complexity. > And with all due respect to PHPlib, we won't change the PHP language > theme and concept to be a better framework for PHPlib. You are not doing this for PHPLIB at all, you are doing this for PHP world domination - see the developments I mentioned above. PHP _must_ become a fully featured programming language, OO, references and all, because people are now using it as such. Maybe you did not intend PHP to do all this, but this is no longer entirely your baby anymore, as it hasn't been Rasmus' for quite some time now. Kristian -- Kristian Köhntopp, NetUSE AG Siemenswall, D-24107 Kiel Tel: +49 431 386 436 00, Fax: +49 431 386 435 99 Using PHP3? See our web development library at http://phplib.netuse.de/