1) What about using a new open tag?
<?php
if (strpos("hello", "lo")) {...
if (in_array(1, [1,2,3])) {...
<?php6
if (str_pos("hello", "lo")) {...
if (in_array([1,2,3], 1)) {...
if (strpos("hello", "lo")) {... // fatal error
$a = [1,2,3]; // ok
$a = array(1,2,3); // fatal error
Those who want to switch their code to the php6 standard can do it,
those who want to keep their code as it is are also happy.
Those who want to switch only some files in their code are also fine.
2) Another option would be adding String and Array classes (similar to
DateTime):
<?php
String::setDefaultEncoding("UTF-8");
if (String::pos("hello", "lo")) {...
if (Array::contains([1,2,3], 1)) {...
or:
$s = new String("hello", "UTF-8");
if ($s->pos("lo")) {...
echo $s->htmlSpecialChars();
echo $s->convert("ISO-8859-1");
$a = new Array([1,2,3]);
if ($a->contains(1)) {...
Regards,
Thomas
On Sat, Jan 26, 2013 at 3:43 AM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> Hi!
>
>> Realistically couldn't we just introduce a configuration parameter to
>> keep "the inconsistent parameter order," perhaps along with a script to
>> suggest the changes needed to bring some code up to speed?
>
> People think that "introduce a configuration parameter" is a solution to
> almost any BC problem in the engine. It's not true, actually it's the
> opposite - now you have to maintain two code bases, one for one value of
> the parameter and one for another. Now imagine there's 10 such
> parameters, for different things in PHP, and you get 1024 options to
> test you application on. That's why we try to reduce behavior-modifying
> options to a minimum. Config options are for configuration, not for
> changing engine behavior in BC-breaking way. That's one of the reasons
> why magic_* were not a good idea and we had to get rid of them.
>
> And imagine integrating a library that is written with one set of engine
> options into application that expects another set of options. Now
> imagine application that uses a dozen of third-party libraries (in
> current open-source world, it's not too many at all), each of them
> expecting its own set of engine-modifying options. It would very quickly
> become a complete nightmare.
>
> So I think we should try to keep PHP behavior unified and avoid
> behavior-modifying switches as much as possible.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
