Re: Unfulfilled promises... forever experimental extensions... all over again

From: Date: Fri, 27 Aug 2004 07:24:24 +0000
Subject: Re: Unfulfilled promises... forever experimental extensions... all over again
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-12402@lists.php.net to get a copy of this message
Naik, Roshan wrote:
Andi wrote:
Oh boy, if you don't see the difference between "concrete
Once again I am *not* asking to hold a whip to the developers who are working for free here. Just dont include code until its ready. Let them mature elsewhere and carefully pick the best of the lot. Invite implementations for a given feature. So people know their work may have a good chance of going somehwere...if they did a good job. It encourages healthy competition and improves product quality. PHP has been bitten by this before many times, lets not let it happen again. And lets not advertise experimental features. If this wasn't the case many of the libraries wouldn't be
available in the "glue" named PHP. ext/sockets is experimental but if the authot didn't bother to release the code for this reason noone will benefit from its existance. Now it is marked experimental, so whoever needs the functionality will use it. The people who don't like experimental stuff will stay around or if they have enough skills they may contact the maintainer and help and even clear whether the extension is still considered EXPERIMENTAL - this is what happened with XML extensions yesterday, Rob Richards removed the experimental tag. Just a side note, I asked Wez Furlong, the author of the streams API, about ext/sockets and he told me that "ext/sockets sucks use streams". Of course he is a little bit biased :), but in fact streams provide almost the same functionality one finds in ext/sockets and sockets become more transparent (like inclusions of files became with inlude 'http://example.org/some.inc"; ). Back to the changing APIs. There are some things one can do to aid himself again API changes. Use classes and wrap things. If the underlying functions and classes change their behaviour for some reason one has to change only the wrapping class. One may use factory methods for instantiating thus even not changing (IMO) one line productional code except the wrapping class (changing may happen but will be less). Consider this example code : <?php class V1 {
        function getInstance() {
                return new V1();
        }
        function doSth($par1, $par2) {
                echo $par1,$par2, "\n";
        }
} class V2 extends V1 {
        function getInstance() {
                return new V2();
        }
        function doSth($par1, $par2) {
                echo $par2,$par1,"\n";
        }
} $a=V1::getInstance(); $a->doSth("foo", "bar"); ?> Let's say that all the code uses V1::getInstance() to get new instance, one can change the method to return an instance of V2 with return new V2(); and then all your code starts to use V2. When you are sure that everything is fine, just go and do search and replace in files of "V1::getInstance()" with "V2::getInstance()". andrey

« previous php.internals (#12402) next »