Andi wrote:
Oh boy, if you don't see the difference between "concrete
suggestions to be
heard that's fine, but try and keep it short, to the point, and
constructive"
There were concrete solutions (if you cared to read. so atleast
read this one all the way)
And were also backed up by others. So not everyone
took offense at it....nor there shold be any need to.
Why is it not concrete ?
Andi wrote:
and the email you sent then it is really preferable to
everyone here for you to stop emailing this list.
So let us know who is included and who is
NOT in that convenient use of "everyone".
We must drop arrognace and work towards encouraging
discussions that can improve the situation moving
forward. Only by encouraging discusssion can
we reach to solutions to such issues.
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.
-Roshan
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