# Binary strings from 6 in 5.2? - Thread: https://externals.io/message/26562 - Original archive: https://news-web.php.net/php.internals/26562 - Started by Matt Wilmas on 2006-11-14T11:50:08+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #26562 — Matt Wilmas — 2006-11-14T11:50:08+00:00 URL: https://externals.io/message/26562#26562 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 --- ## #26569 — Ilia Alshanetsky — 2006-11-14T14:32:09+00:00 URL: https://externals.io/message/26562#26569 · In reply to: #26562 -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 --- ## #26578 — Sara Golemon — 2006-11-14T21:08:50+00:00 URL: https://externals.io/message/26562#26578 · In reply to: #26569 Ilia Alshanetsky wrote: > -1. Let's not transform 5.2 into a placeholder for PHP6. > > > > > > […] > 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 --- ## #26587 — Ilia Alshanetsky — 2006-11-14T21:28:15+00:00 URL: https://externals.io/message/26562#26587 · In reply to: #26578 > 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 --- ## #26589 — Christian Schneider — 2006-11-14T23:05:38+00:00 URL: https://externals.io/message/26562#26589 · In reply to: #26587 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 --- ## #26596 — Wez Furlong — 2006-11-15T06:40:47+00:00 URL: https://externals.io/message/26562#26596 · In reply to: #26578 I am +1 on this idea also. --Wez. > > Ilia Alshanetsky wrote: > > […] > > 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 --- ## #26599 — Derick Rethans — 2006-11-15T08:32:18+00:00 URL: https://externals.io/message/26562#26599 · In reply to: #26578 > 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 --- ## #26619 — Richard Lynch — 2006-11-15T20:17:47+00:00 URL: https://externals.io/message/26562#26619 · In reply to: #26578 > 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? --- ## #26621 — Derick Rethans — 2006-11-15T20:36:44+00:00 URL: https://externals.io/message/26562#26621 · In reply to: #26619 > 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 --- ## #26628 — Rick Widmer — 2006-11-15T21:02:31+00:00 URL: https://externals.io/message/26562#26628 · In reply to: #26619 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...