Hi all,
This is regarding Derick's addition of the (binary) cast in 5.2, and its
discussion. I agree with the others who think it's a good addition so
future code for PHP 6 won't fail with a parse error on a small thing that
could be handled transparently.
But the point of this message is to ask about the "b" binary-string "prefix
thing" from 6: Isn't that a closely-related syntax addition which should
also be included? If so, the attached patch hopefully covers it. :-)
Matt
-1. Let's not transform 5.2 into a placeholder for PHP6.
Hi all,
This is regarding Derick's addition of the (binary) cast in 5.2,
and its
discussion. I agree with the others who think it's a good addition so
future code for PHP 6 won't fail with a parse error on a small
thing that
could be handled transparently.But the point of this message is to ask about the "b" binary-string
"prefix
thing" from 6: Isn't that a closely-related syntax addition which
should
also be included? If so, the attached patch hopefully covers it. :-)Matt
<5_2_binary.txt>
Ilia Alshanetsky
Ilia Alshanetsky wrote:
-1. Let's not transform 5.2 into a placeholder for PHP6.
Hi all,
Matt
<5_2_binary.txt>
I disagree. We're not making 5.2 a placeholder, we're making it a
transitional version. A means of softening the impact of migrating
applications to take advantage of PHP6 which introduces a lot of
interversion compatability issues.
How many applications out there aren't taking advantage of things like
property visibility in PHP5 because they want to remain compatable with
the myriad PHP4 installations? How much are compromises like that
slowing PHP5 adoption?
With something like binary strings it's even more important since they
drastically change how the data is treated in PHP6 and can potentially
cause chunks to be transformed in unexpected ways.
+1 on backporting these types of syntax placeholders.
-Sara
I disagree. We're not making 5.2 a placeholder, we're making it a
transitional version.
It is not a transitional version, what gave you this idea? It is a
standalone version, if we decide to make a transitional version we
should create 5.9 branch or similar and then feel free to stuff it
full of php6 place holders to your heart's content.
A means of softening the impact of migrating applications to take
advantage of PHP6 which introduces a lot of interversion
compatability issues.
Just because behavior of something had changed in php6 does not mean
it should change in php5 as well. It is the job of new releases to be
backwards compatible, not old releases to be forward compatible.
How many applications out there aren't taking advantage of things
like property visibility in PHP5 because they want to remain
compatable with the myriad PHP4 installations? How much are
compromises like that slowing PHP5 adoption?
People who need this functionality migrate to PHP5, those can live
without and are perfectly happy with PHP 4 continue using that...
Ilia Alshanetsky
Ilia Alshanetsky wrote:
Just because behavior of something had changed in php6 does not mean it
should change in php5 as well. It is the job of new releases to be
backwards compatible, not old releases to be forward compatible.
While I agree not to clutter PHP5 too much I can see the point in adding
some stuff here.
It would have been easier to prepare PHP4 code to the PHP5 clone
migration if a clone functionality would have been made available early
in PHP4 when it was clear what the PHP5 way of cloning would be.
Now I'm stuck with this ugly work-around if I want to be cross-version
compatible:
function &cloneobj(&$object)
{
$result = (is_object($object) && version_compare(zend_version(), 2,
'>=')) ? clone($object) : $object;
return $result; # PHP internals need a tmp var to return by ref
}
While I'm as of yet unsure how and how often binary strings are going to
be used I think it is worth considering opening up the migration path early.
- Chris
I am +1 on this idea also.
--Wez.
Ilia Alshanetsky wrote:
-1. Let's not transform 5.2 into a placeholder for PHP6.
Hi all,
Matt
<5_2_binary.txt>I disagree. We're not making 5.2 a placeholder, we're making it a
transitional version. A means of softening the impact of migrating
applications to take advantage of PHP6 which introduces a lot of
interversion compatability issues.How many applications out there aren't taking advantage of things like
property visibility in PHP5 because they want to remain compatable with
the myriad PHP4 installations? How much are compromises like that
slowing PHP5 adoption?With something like binary strings it's even more important since they
drastically change how the data is treated in PHP6 and can potentially
cause chunks to be transformed in unexpected ways.+1 on backporting these types of syntax placeholders.
-Sara
With something like binary strings it's even more important since they
drastically change how the data is treated in PHP6 and can potentially cause
chunks to be transformed in unexpected ways.+1 on backporting these types of syntax placeholders.
Same +1 from me.
Derick
How many applications out there aren't taking advantage of things like
property visibility in PHP5 because they want to remain compatable
with
the myriad PHP4 installations? How much are compromises like that
slowing PHP5 adoption?
How many sysadmins and other decision-makers out there aren't adopting
PHP5.x, much less 6.x, because we've changed too many things too
quickly in BC-incompatible ways?
THAT is what is slowing the adoption rate, not the applications
developers not WANTING to use the better code.
It's the fact that one cannot easily migrate code.
And while it's trivial for some to set up 5 on another machine and
proxyhost or whatever, for many folks, that's not really an option.
I didn't even read the patch, but unless it's guaranteed NOT to break
anything at all in php4 (yes, 4, not 5):
-1
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
I didn't even read the patch, but unless it's guaranteed NOT to break
anything at all in php4 (yes, 4, not 5):
-1
It's guaranteed not to break anything, as the syntax currently just
throws a parse error for this stuff.
Derick
Richard Lynch wrote:
How many sysadmins and other decision-makers out there aren't adopting
PHP5.x, much less 6.x, because we've changed too many things too
quickly in BC-incompatible ways?THAT is what is slowing the adoption rate, not the applications
developers not WANTING to use the better code.It's the fact that one cannot easily migrate code.
I just thought that deserved to be repeated...