Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
Hi Christoph, On Tue, Sep 12, 2017 at 10:04 PM, Christoph M. Becker wrote: > On 12.09.2017 at 14:52, François Laupretre wrote: > > > What about making PHP 8 100% case-sensitive (except true/false) ? If we > > announce it years in advance, it is possible, IMO. > > I don't think we can do that. Consider, for instance, ext/gd where all > functions are actually in lower case, but I've seen a lot of code > written in pascal or camel case to make the functions better readable, e.g. > > imageCreateFromJpeg() vs. imagecreatefromjpeg() > Consistent function names at the same time, perhaps? https://wiki.php.net/rfc/consistent_function_names -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi! On 9/15/17 2:20 PM, ilija.tov...@me.com wrote: >> no, as there is no special risks > > There certainly is. No other function (as far as I’m aware) mutates your > local symbol table. This means you need to know exactly what symbols are Sure, because this is the function to mutate your local symbol table! Why would we need more of them? It's like saying unlink() should be removed because it deletes files and no other function does it, so it's super-dangerous! > defined and what kind of data you’ll receive when calling `extract`. So > basically this is only safe right at the beginning of your function, and > even then it can override your other parameters. Even with trusted data > this can hardly be considered safe. It does exactly what you tell it to do. Extracts array into local symbol table. If you don't need that, don't use that function. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi Yasuo
These sound good to me!
There’s still a smaller vulnerability of defining variables beforehand:
```
$data = ['hasAccess' => true];
export($data);
if ($user->isAdmin()) {
$hasAccess = true;
}
if (isset($hasAccess) && $hasAccess === true) {
print 'Bingo';
}
```
but code like this should be rather rare.
Regards
On 15 Sep 2017, 23:17 +0200, Yasuo Ohgaki , wrote:
> Hi all,
>
> On Sat, Sep 16, 2017 at 2:50 AM, Sara Golemon wrote:
>
> > On Fri, Sep 15, 2017 at 1:35 PM, wrote:
> > > The `extract` function takes an associative array and
> > > puts it into the local symbol table.
> > > http://php.net/manual/en/function.extract.php
> > >
> > > I seriously doubt the usefulness of this function,
> > > especially looking at the potential risks. The fact
> > > that overwriting the local variables is the default
> > > behaviour doesn’t make it any better. I suggest
> > > deprecating it in PHP 7.3 and removing it in 8.
> > >
> > Preface: I despise extract() as well. It's breaks assumptions for
> > both the developer and the runtime. I save some of my frowniest of
> > faces for extract().
> >
> > That said...
> >
> > > I can see it’s usefulness in this case.
> > > But wouldn’t it be better to implement this by hand
> > > in these rare cases (it’s 3 lines of code) instead of
> > > encouraging the pollution of the symbol table by
> > > unknown input? It’s also clearer since people who
> > > don’t know the `extract` function probably don’t
> > > expect it to mutate the local symbol table.
> > >
> > Let's be clear on what that looks like: foreach ($data as $key =
> > $value) { $$key = $value; }
> >
> > This is SO MUCH WORSE for several reasons, no least of all what
> > happens when $data contains keys named 'data', 'key', or 'value'.
> >
> > I'd like to kill extract(), but it does have a reason for being, and I
> > couldn't in any good conscience support removing it without a
> > replacement that's at least marginally better.
> >
>
> The security issue regarding extract() are:
> - Unintended variable creation. e.g. $admin_flag = ture
> - Unintended variable modification. e.g. $admin_flag = ture
>
> Instead of removing/deprecating extract(),
> - Add EXTR_EXCEPTION flag that throws exception for overwriting.
> (There are many flags, but no error/exception flag. This isn't good)
> - Require prefix. (User may still set '' as prefix)
>
> We may do:
> - Add EXTR_EXCEPTION flag in 7.3
> - Make all three parameters required parameter set EXTR_ECEPTION a default
> flag in 8.0
>
> With this way, we'll have better compatibility with older PHP and better
> security with extract().
>
> https://github.com/php/php-src/blob/master/ext/standard/array.c#L2459
> Since it checks valid flags, we wouldn't have compatibility for current
> versions unless
> released versions code is modified for it.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
> no, as there is no special risks
There certainly is. No other function (as far as I’m aware) mutates your local
symbol table. This means you need to know exactly what symbols are defined and
what kind of data you’ll receive when calling `extract`. So basically this is
only safe right at the beginning of your function, and even then it can
override your other parameters. Even with trusted data this can hardly be
considered safe.
```
function foo(array $data, $bar) {
extract($data);
print($bar);
}
$this->foo(['bar' => 'baz'], 'bar’); // “baz"
```
Regards
On 15 Sep 2017, 23:05 +0200, Stanislav Malyshev , wrote:
> Hi!
>
> > Dangerous meaning that if given untrusted input someone could mess with
> > the behaviour of your code. There are risks and benefits to every
>
> Same as many other functions. Given untrusted input, unlink() could
> delete files on your hard drive, and file_put_contents() could overwrite
> your data or send it to unauthorized party. That's not the reason to
> remove these functions.
>
> > solution. Certainly you’d agree that in some cases the risks outweigh
> > the benefits.
>
> In some cases, yes. In this case, no, as there is no special risks not
> existing in many other functions. Any function that has side effects
> could do something unexpected when you give it unexpected input. Since
> we're not converting PHP to be purely functional language just yet, the
> solution is to use functions correctly, not remove them.
> --
> Stas Malyshev
> smalys...@gmail.com
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi all,
On Sat, Sep 16, 2017 at 2:50 AM, Sara Golemon wrote:
> On Fri, Sep 15, 2017 at 1:35 PM, wrote:
> > The `extract` function takes an associative array and
> > puts it into the local symbol table.
> > http://php.net/manual/en/function.extract.php
> >
> > I seriously doubt the usefulness of this function,
> > especially looking at the potential risks. The fact
> > that overwriting the local variables is the default
> > behaviour doesn’t make it any better. I suggest
> > deprecating it in PHP 7.3 and removing it in 8.
> >
> Preface: I despise extract() as well. It's breaks assumptions for
> both the developer and the runtime. I save some of my frowniest of
> faces for extract().
>
> That said...
>
> > I can see it’s usefulness in this case.
> > But wouldn’t it be better to implement this by hand
> > in these rare cases (it’s 3 lines of code) instead of
> > encouraging the pollution of the symbol table by
> > unknown input? It’s also clearer since people who
> > don’t know the `extract` function probably don’t
> > expect it to mutate the local symbol table.
> >
> Let's be clear on what that looks like: foreach ($data as $key =>
> $value) { $$key = $value; }
>
> This is SO MUCH WORSE for several reasons, no least of all what
> happens when $data contains keys named 'data', 'key', or 'value'.
>
> I'd like to kill extract(), but it does have a reason for being, and I
> couldn't in any good conscience support removing it without a
> replacement that's at least marginally better.
>
The security issue regarding extract() are:
- Unintended variable creation. e.g. $admin_flag = ture
- Unintended variable modification. e.g. $admin_flag = ture
Instead of removing/deprecating extract(),
- Add EXTR_EXCEPTION flag that throws exception for overwriting.
(There are many flags, but no error/exception flag. This isn't good)
- Require prefix. (User may still set '' as prefix)
We may do:
- Add EXTR_EXCEPTION flag in 7.3
- Make all three parameters required parameter set EXTR_ECEPTION a default
flag in 8.0
With this way, we'll have better compatibility with older PHP and better
security with extract().
https://github.com/php/php-src/blob/master/ext/standard/array.c#L2459
Since it checks valid flags, we wouldn't have compatibility for current
versions unless
released versions code is modified for it.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi! > Dangerous meaning that if given untrusted input someone could mess with > the behaviour of your code. There are risks and benefits to every Same as many other functions. Given untrusted input, unlink() could delete files on your hard drive, and file_put_contents() could overwrite your data or send it to unauthorized party. That's not the reason to remove these functions. > solution. Certainly you’d agree that in some cases the risks outweigh > the benefits. In some cases, yes. In this case, no, as there is no special risks not existing in many other functions. Any function that has side effects could do something unexpected when you give it unexpected input. Since we're not converting PHP to be purely functional language just yet, the solution is to use functions correctly, not remove them. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi Stas Dangerous meaning that if given untrusted input someone could mess with the behaviour of your code. There are risks and benefits to every solution. Certainly you’d agree that in some cases the risks outweigh the benefits. As Sara pointed out, this might not be the case here as there’s no obvious way of mimicking `extract`s behaviour without introducing at least one local variable that could be overwritten. Thanks for the feedback everybody! Regards On 15 Sep 2017, 22:10 +0200, Stanislav Malyshev , wrote: > Hi! > > > As a second parameter the `extract` function takes some options to > > make this function less dangerous, like `EXTR_SKIP` that > > I'd start with specifying what exactly is "dangerous" in this function. > So far I don't see any specific danger. You can shoot yourself in the > foot, so you can with many other tools in the language. > > > I seriously doubt the usefulness of this function, especially looking > > at the potential risks. The fact that overwriting the local variables > > Which risks? This function is used by real-life code, and unless you do > something like extract($_GET) in global scope I don't see any problem. > With extract($_GET) we could then also propose to remove all file > functions because fopen($_GET['filename']) or unlink($_GET['filename']) > are also dangerous. But if you use it properly, I don't see what "risks" > are there. > > > Any thoughts? > > -1 so far, I don't see what problem you are trying to solve. > > -- > Stas Malyshev > smalys...@gmail.com
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi! > As a second parameter the `extract` function takes some options to > make this function less dangerous, like `EXTR_SKIP` that I'd start with specifying what exactly is "dangerous" in this function. So far I don't see any specific danger. You can shoot yourself in the foot, so you can with many other tools in the language. > I seriously doubt the usefulness of this function, especially looking > at the potential risks. The fact that overwriting the local variables Which risks? This function is used by real-life code, and unless you do something like extract($_GET) in global scope I don't see any problem. With extract($_GET) we could then also propose to remove all file functions because fopen($_GET['filename']) or unlink($_GET['filename']) are also dangerous. But if you use it properly, I don't see what "risks" are there. > Any thoughts? -1 so far, I don't see what problem you are trying to solve. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
> On 16 Sep 2017, at 01:27, Arvids Godjuks wrote:
>
> 2017-09-15 20:52 GMT+03:00 Ryan Pallas :
>
>>> On Fri, Sep 15, 2017 at 11:38 AM, wrote:
>>>
>>> Hi Ryan
>>>
>>> I can see your argument. The reasoning behind it is that a function in
>> the
>>> standard library should not encourage unsafe code. Admittedly, since this
>>> function is rarely used except for templating systems one could call
>> this a
>>> non-issue. I just wanted to bring it up.
>>>
>>
>> That makes sense. What about performance difference? On a reasonable sized
>> array (not 10k items and not 2) which is faster?
>>
>> extract($array);
>>
>> - or -
>>
>> foreach ($array as $key => $value)
>>$$key = $value;
>>
>> Honestly, I don't know (ps 2 lines without braces instead of 3!)
>>
>>
>>>
>>> Regards
>>>
>>>
>>> On 15 Sep 2017, 19:30 +0200, Ryan Pallas , wrote:
>>>
>>>
>>>
>>> On Sep 15, 2017 11:22 AM, wrote:
>>>
>>> Hi!
>>>
>>> The `extract` function takes an associative array and puts it into the
>>> local symbol table.
>>> http://php.net/manual/en/function.extract.php
>>>
>>> ```
>>> $array = [
>>>‘foo’ => ‘foo’,
>>>‘bar’ => ‘bar’,
>>> ];
>>>
>>> extract($array);
>>>
>>> print $foo; // "foo"
>>> ```
>>>
>>> As a second parameter the `extract` function takes some options to make
>>> this function less dangerous, like `EXTR_SKIP` that prevents an existing
>>> local variable of being overwritten. There’s a few more options, go ahead
>>> and take a look at the documentation. `EXTR_OVERWRITE` is the default one
>>> though. You can also pass a prefix for the variable names as a third
>>> argument.
>>>
>>> I seriously doubt the usefulness of this function, especially looking at
>>> the potential risks. The fact that overwriting the local variables is the
>>> default behaviour doesn’t make it any better. I suggest deprecating it in
>>> PHP 7.3 and removing it in 8.
>>>
>>> In a whole Symfony-Stack (3.4) with all of it’s dependencies I could only
>>> find two usages of this function, both of which could be easily rewritten
>>> in vanilla PHP:
>>> https://github.com/symfony/symfony/blob/master/src/Symfony/
>>> Component/Templating/PhpEngine.php#L148
>>> https://github.com/symfony/symfony/blob/master/src/Symfony/
>>> Component/Templating/PhpEngine.php#L158
>>>
>>> Only downside: A polyfill is probably impossible since you cannot mutate
>>> the local symbol table of the callee (as far as I’m aware).
>>>
>>> Any thoughts?
>>>
>>>
>>> I see no gain by removing this function. I've also seen it used for
>>> templating quite often. Yes the functionality could be changed not to use
>>> extract and end up working the same to the consumer but why make people
>>> rewrite these things for no apparent gain (and likely a small performance
>>> hit)?
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>>
>>
>
> Hi Ryan,
> well, basically, none. Results are from a Q6600 machine and under windows,
> so your mileage probably gonna be quite better :)
>
> C:\Users\psihius\Documents\web>php -v
> PHP 7.1.5 (cli) (built: May 9 2017 19:48:36) ( NTS MSVC14 (Visual C++
> 2015) x64 )
> Copyright (c) 1997-2017 The PHP Group
> Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
> C:\Users\psihius\Documents\web>php -d memory_limit=-1 test.php
> 6.884626150131226 - Creating arrays
> 2.035606861114502 - foreach
> 2.128609180450439 - extract
>
> The code:
>
> define('ITERATIONS', 1000);
>
> $__time = microtime(true);
>
> $__array = $__array2 = [];
> for ($__i = 0; $__i < ITERATIONS; ++$__i) {
>$__array['a'.$__i] = $__i;
>$__array2['b'.$__i] = $__i;
> }
> echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;
>
> $__time = microtime(true);
> foreach ($__array as $__key => $__variable) {
>$$__key = $__variable;
> }
> echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;
>
> $__time = microtime(true);
> foreach ($__array2 as $__key => $__variable) {
>$$__key = $__variable;
> }
> echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;
>
> --
> Arvīds Godjuks
>
> +371 26 851 664
> arvids.godj...@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius
Hi all,
If you want to reduce unintended consequences while retaining functionality,
the default flag could be changed to EXTR_SKIP. Yes it affects BC but it's also
much simpler to fix than if the functionality is gone completely, and in the
case of templating it's probably already used that way in most cases anyway.
Cheers
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi Sara
That is indeed a very good point. Haven't thought of that one.
Regards
> On 15. Sep 2017, at 19:50, Sara Golemon wrote:
>
>> On Fri, Sep 15, 2017 at 1:35 PM, wrote:
>> The `extract` function takes an associative array and
>> puts it into the local symbol table.
>> http://php.net/manual/en/function.extract.php
>>
>> I seriously doubt the usefulness of this function,
>> especially looking at the potential risks. The fact
>> that overwriting the local variables is the default
>> behaviour doesn’t make it any better. I suggest
>> deprecating it in PHP 7.3 and removing it in 8.
>>
> Preface: I despise extract() as well. It's breaks assumptions for
> both the developer and the runtime. I save some of my frowniest of
> faces for extract().
>
> That said...
>
>> I can see it’s usefulness in this case.
>> But wouldn’t it be better to implement this by hand
>> in these rare cases (it’s 3 lines of code) instead of
>> encouraging the pollution of the symbol table by
>> unknown input? It’s also clearer since people who
>> don’t know the `extract` function probably don’t
>> expect it to mutate the local symbol table.
>>
> Let's be clear on what that looks like: foreach ($data as $key =>
> $value) { $$key = $value; }
>
> This is SO MUCH WORSE for several reasons, no least of all what
> happens when $data contains keys named 'data', 'key', or 'value'.
>
> I'd like to kill extract(), but it does have a reason for being, and I
> couldn't in any good conscience support removing it without a
> replacement that's at least marginally better.
>
> -Sara
>
> --
> 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
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
2017-09-15 20:52 GMT+03:00 Ryan Pallas :
> On Fri, Sep 15, 2017 at 11:38 AM, wrote:
>
> > Hi Ryan
> >
> > I can see your argument. The reasoning behind it is that a function in
> the
> > standard library should not encourage unsafe code. Admittedly, since this
> > function is rarely used except for templating systems one could call
> this a
> > non-issue. I just wanted to bring it up.
> >
>
> That makes sense. What about performance difference? On a reasonable sized
> array (not 10k items and not 2) which is faster?
>
> extract($array);
>
> - or -
>
> foreach ($array as $key => $value)
> $$key = $value;
>
> Honestly, I don't know (ps 2 lines without braces instead of 3!)
>
>
> >
> > Regards
> >
> >
> > On 15 Sep 2017, 19:30 +0200, Ryan Pallas , wrote:
> >
> >
> >
> > On Sep 15, 2017 11:22 AM, wrote:
> >
> > Hi!
> >
> > The `extract` function takes an associative array and puts it into the
> > local symbol table.
> > http://php.net/manual/en/function.extract.php
> >
> > ```
> > $array = [
> > ‘foo’ => ‘foo’,
> > ‘bar’ => ‘bar’,
> > ];
> >
> > extract($array);
> >
> > print $foo; // "foo"
> > ```
> >
> > As a second parameter the `extract` function takes some options to make
> > this function less dangerous, like `EXTR_SKIP` that prevents an existing
> > local variable of being overwritten. There’s a few more options, go ahead
> > and take a look at the documentation. `EXTR_OVERWRITE` is the default one
> > though. You can also pass a prefix for the variable names as a third
> > argument.
> >
> > I seriously doubt the usefulness of this function, especially looking at
> > the potential risks. The fact that overwriting the local variables is the
> > default behaviour doesn’t make it any better. I suggest deprecating it in
> > PHP 7.3 and removing it in 8.
> >
> > In a whole Symfony-Stack (3.4) with all of it’s dependencies I could only
> > find two usages of this function, both of which could be easily rewritten
> > in vanilla PHP:
> > https://github.com/symfony/symfony/blob/master/src/Symfony/
> > Component/Templating/PhpEngine.php#L148
> > https://github.com/symfony/symfony/blob/master/src/Symfony/
> > Component/Templating/PhpEngine.php#L158
> >
> > Only downside: A polyfill is probably impossible since you cannot mutate
> > the local symbol table of the callee (as far as I’m aware).
> >
> > Any thoughts?
> >
> >
> > I see no gain by removing this function. I've also seen it used for
> > templating quite often. Yes the functionality could be changed not to use
> > extract and end up working the same to the consumer but why make people
> > rewrite these things for no apparent gain (and likely a small performance
> > hit)?
> >
> >
> > Regards
> >
> >
> >
> >
>
Hi Ryan,
well, basically, none. Results are from a Q6600 machine and under windows,
so your mileage probably gonna be quite better :)
C:\Users\psihius\Documents\web>php -v
PHP 7.1.5 (cli) (built: May 9 2017 19:48:36) ( NTS MSVC14 (Visual C++
2015) x64 )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
C:\Users\psihius\Documents\web>php -d memory_limit=-1 test.php
6.884626150131226 - Creating arrays
2.035606861114502 - foreach
2.128609180450439 - extract
The code:
define('ITERATIONS', 1000);
$__time = microtime(true);
$__array = $__array2 = [];
for ($__i = 0; $__i < ITERATIONS; ++$__i) {
$__array['a'.$__i] = $__i;
$__array2['b'.$__i] = $__i;
}
echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;
$__time = microtime(true);
foreach ($__array as $__key => $__variable) {
$$__key = $__variable;
}
echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;
$__time = microtime(true);
foreach ($__array2 as $__key => $__variable) {
$$__key = $__variable;
}
echo number_format(microtime(true) - $__time, 15, '.', ''), PHP_EOL;
--
Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi, (accidentally replied to only OP)... > On Sep 15, 2017, at 1:35 PM, ilija.tov...@me.com wrote: > > Hi Marco > > I can see it’s usefulness in this case. > > But wouldn’t it be better to implement this by hand in these rare cases (it’s > 3 lines of code) instead of encouraging the pollution of the symbol table by > unknown input? It’s also clearer since people who don’t know the `extract` > function probably don’t expect it to mutate the local symbol table. This argument is predicated on the assumption that my input is unknown. This assumption is not universal to all codebases as implied. There are many "foot guns" in every language and framework. I don't think it is necessary (or wise) for the language to assume responsibility for abuse. This is the same line of reasoning that could be used to justify removing serialize/deserialize because a developer could "accidentally a tent" or we could build safer options into the feature (as you've already described) Just my 2c
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
On Fri, Sep 15, 2017 at 11:50 AM, Sara Golemon wrote:
> On Fri, Sep 15, 2017 at 1:35 PM, wrote:
> > The `extract` function takes an associative array and
> > puts it into the local symbol table.
> > http://php.net/manual/en/function.extract.php
> >
> > I seriously doubt the usefulness of this function,
> > especially looking at the potential risks. The fact
> > that overwriting the local variables is the default
> > behaviour doesn’t make it any better. I suggest
> > deprecating it in PHP 7.3 and removing it in 8.
> >
> Preface: I despise extract() as well. It's breaks assumptions for
> both the developer and the runtime. I save some of my frowniest of
> faces for extract().
>
> That said...
>
> > I can see it’s usefulness in this case.
> > But wouldn’t it be better to implement this by hand
> > in these rare cases (it’s 3 lines of code) instead of
> > encouraging the pollution of the symbol table by
> > unknown input? It’s also clearer since people who
> > don’t know the `extract` function probably don’t
> > expect it to mutate the local symbol table.
> >
> Let's be clear on what that looks like: foreach ($data as $key =>
> $value) { $$key = $value; }
>
> This is SO MUCH WORSE for several reasons, no least of all what
> happens when $data contains keys named 'data', 'key', or 'value'.
>
This is a very good point. I hadn't thought about keys being named that
way, but obviously they could! *grumble*
>
> I'd like to kill extract(), but it does have a reason for being, and I
> couldn't in any good conscience support removing it without a
> replacement that's at least marginally better.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
On Fri, Sep 15, 2017 at 11:38 AM, wrote: > Hi Ryan > > I can see your argument. The reasoning behind it is that a function in the > standard library should not encourage unsafe code. Admittedly, since this > function is rarely used except for templating systems one could call this a > non-issue. I just wanted to bring it up. > That makes sense. What about performance difference? On a reasonable sized array (not 10k items and not 2) which is faster? extract($array); - or - foreach ($array as $key => $value) $$key = $value; Honestly, I don't know (ps 2 lines without braces instead of 3!) > > Regards > > > On 15 Sep 2017, 19:30 +0200, Ryan Pallas , wrote: > > > > On Sep 15, 2017 11:22 AM, wrote: > > Hi! > > The `extract` function takes an associative array and puts it into the > local symbol table. > http://php.net/manual/en/function.extract.php > > ``` > $array = [ > ‘foo’ => ‘foo’, > ‘bar’ => ‘bar’, > ]; > > extract($array); > > print $foo; // "foo" > ``` > > As a second parameter the `extract` function takes some options to make > this function less dangerous, like `EXTR_SKIP` that prevents an existing > local variable of being overwritten. There’s a few more options, go ahead > and take a look at the documentation. `EXTR_OVERWRITE` is the default one > though. You can also pass a prefix for the variable names as a third > argument. > > I seriously doubt the usefulness of this function, especially looking at > the potential risks. The fact that overwriting the local variables is the > default behaviour doesn’t make it any better. I suggest deprecating it in > PHP 7.3 and removing it in 8. > > In a whole Symfony-Stack (3.4) with all of it’s dependencies I could only > find two usages of this function, both of which could be easily rewritten > in vanilla PHP: > https://github.com/symfony/symfony/blob/master/src/Symfony/ > Component/Templating/PhpEngine.php#L148 > https://github.com/symfony/symfony/blob/master/src/Symfony/ > Component/Templating/PhpEngine.php#L158 > > Only downside: A polyfill is probably impossible since you cannot mutate > the local symbol table of the callee (as far as I’m aware). > > Any thoughts? > > > I see no gain by removing this function. I've also seen it used for > templating quite often. Yes the functionality could be changed not to use > extract and end up working the same to the consumer but why make people > rewrite these things for no apparent gain (and likely a small performance > hit)? > > > Regards > > > >
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
On Fri, Sep 15, 2017 at 1:35 PM, wrote:
> The `extract` function takes an associative array and
> puts it into the local symbol table.
> http://php.net/manual/en/function.extract.php
>
> I seriously doubt the usefulness of this function,
> especially looking at the potential risks. The fact
> that overwriting the local variables is the default
> behaviour doesn’t make it any better. I suggest
> deprecating it in PHP 7.3 and removing it in 8.
>
Preface: I despise extract() as well. It's breaks assumptions for
both the developer and the runtime. I save some of my frowniest of
faces for extract().
That said...
> I can see it’s usefulness in this case.
> But wouldn’t it be better to implement this by hand
> in these rare cases (it’s 3 lines of code) instead of
> encouraging the pollution of the symbol table by
> unknown input? It’s also clearer since people who
> don’t know the `extract` function probably don’t
> expect it to mutate the local symbol table.
>
Let's be clear on what that looks like: foreach ($data as $key =>
$value) { $$key = $value; }
This is SO MUCH WORSE for several reasons, no least of all what
happens when $data contains keys named 'data', 'key', or 'value'.
I'd like to kill extract(), but it does have a reason for being, and I
couldn't in any good conscience support removing it without a
replacement that's at least marginally better.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi Ryan I can see your argument. The reasoning behind it is that a function in the standard library should not encourage unsafe code. Admittedly, since this function is rarely used except for templating systems one could call this a non-issue. I just wanted to bring it up. Regards On 15 Sep 2017, 19:30 +0200, Ryan Pallas , wrote: > > > > On Sep 15, 2017 11:22 AM, wrote: > > > Hi! > > > > > > The `extract` function takes an associative array and puts it into the > > > local symbol table. > > > http://php.net/manual/en/function.extract.php > > > > > > ``` > > > $array = [ > > > ‘foo’ => ‘foo’, > > > ‘bar’ => ‘bar’, > > > ]; > > > > > > extract($array); > > > > > > print $foo; // "foo" > > > ``` > > > > > > As a second parameter the `extract` function takes some options to make > > > this function less dangerous, like `EXTR_SKIP` that prevents an existing > > > local variable of being overwritten. There’s a few more options, go ahead > > > and take a look at the documentation. `EXTR_OVERWRITE` is the default one > > > though. You can also pass a prefix for the variable names as a third > > > argument. > > > > > > I seriously doubt the usefulness of this function, especially looking at > > > the potential risks. The fact that overwriting the local variables is the > > > default behaviour doesn’t make it any better. I suggest deprecating it in > > > PHP 7.3 and removing it in 8. > > > > > > In a whole Symfony-Stack (3.4) with all of it’s dependencies I could only > > > find two usages of this function, both of which could be easily rewritten > > > in vanilla PHP: > > > https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Templating/PhpEngine.php#L148 > > > https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Templating/PhpEngine.php#L158 > > > > > > Only downside: A polyfill is probably impossible since you cannot mutate > > > the local symbol table of the callee (as far as I’m aware). > > > > > > Any thoughts? > > I see no gain by removing this function. I've also seen it used for > templating quite often. Yes the functionality could be changed not to use > extract and end up working the same to the consumer but why make people > rewrite these things for no apparent gain (and likely a small performance > hit)? > > > > > > > Regards > > > > > > >
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi, On 15 Sep 2017 19:37, wrote: Hi Marco I can see it’s usefulness in this case. But wouldn’t it be better to implement this by hand in these rare cases (it’s 3 lines of code) instead of encouraging the pollution of the symbol table by unknown input? It’s also clearer since people who don’t know the `extract` function probably don’t expect it to mutate the local symbol table. Cheers On 15 Sep 2017, 19:26 +0200, Marco Pivetta , wrote: Heya, This is typically used in templating engines. The one I worked on is https://github.com/zendframework/zend-view/blob/ 5523511b6771cb6c060a77f6777426526a8db5ab/src/Renderer/ PhpRenderer.php#L491-L492 Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Fri, Sep 15, 2017 at 7:20 PM, wrote: Hi! The `extract` function takes an associative array and puts it into the local symbol table. http://php.net/manual/en/function.extract.php ``` $array = [ ‘foo’ => ‘foo’, ‘bar’ => ‘bar’, ]; extract($array); print $foo; // "foo" ``` As a second parameter the `extract` function takes some options to make this function less dangerous, like `EXTR_SKIP` that prevents an existing local variable of being overwritten. There’s a few more options, go ahead and take a look at the documentation. `EXTR_OVERWRITE` is the default one though. You can also pass a prefix for the variable names as a third argument. I seriously doubt the usefulness of this function, especially looking at the potential risks. The fact that overwriting the local variables is the default behaviour doesn’t make it any better. I suggest deprecating it in PHP 7.3 and removing it in 8. In a whole Symfony-Stack (3.4) with all of it’s dependencies I could only find two usages of this function, both of which could be easily rewritten in vanilla PHP: https://github.com/symfony/symfony/blob/master/src/ Symfony/Component/Templating/PhpEngine.php#L148 https://github.com/symfony/symfony/blob/master/src/ Symfony/Component/Templating/PhpEngine.php#L158 Only downside: A polyfill is probably impossible since you cannot mutate the local symbol table of the callee (as far as I’m aware). Any thoughts? Regards Absolutely, can be replaced with a loop indeed.
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi Marco I can see it’s usefulness in this case. But wouldn’t it be better to implement this by hand in these rare cases (it’s 3 lines of code) instead of encouraging the pollution of the symbol table by unknown input? It’s also clearer since people who don’t know the `extract` function probably don’t expect it to mutate the local symbol table. Cheers On 15 Sep 2017, 19:26 +0200, Marco Pivetta , wrote: > Heya, > > This is typically used in templating engines. > The one I worked on is > https://github.com/zendframework/zend-view/blob/5523511b6771cb6c060a77f6777426526a8db5ab/src/Renderer/PhpRenderer.php#L491-L492 > > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > On Fri, Sep 15, 2017 at 7:20 PM, wrote: > > > Hi! > > > > The `extract` function takes an associative array and puts it into the > > local symbol table. > > http://php.net/manual/en/function.extract.php > > > > ``` > > $array = [ > > ‘foo’ => ‘foo’, > > ‘bar’ => ‘bar’, > > ]; > > > > extract($array); > > > > print $foo; // "foo" > > ``` > > > > As a second parameter the `extract` function takes some options to make > > this function less dangerous, like `EXTR_SKIP` that prevents an existing > > local variable of being overwritten. There’s a few more options, go ahead > > and take a look at the documentation. `EXTR_OVERWRITE` is the default one > > though. You can also pass a prefix for the variable names as a third > > argument. > > > > I seriously doubt the usefulness of this function, especially looking at > > the potential risks. The fact that overwriting the local variables is the > > default behaviour doesn’t make it any better. I suggest deprecating it in > > PHP 7.3 and removing it in 8. > > > > In a whole Symfony-Stack (3.4) with all of it’s dependencies I could only > > find two usages of this function, both of which could be easily rewritten > > in vanilla PHP: > > https://github.com/symfony/symfony/blob/master/src/ > > Symfony/Component/Templating/PhpEngine.php#L148 > > https://github.com/symfony/symfony/blob/master/src/ > > Symfony/Component/Templating/PhpEngine.php#L158 > > > > Only downside: A polyfill is probably impossible since you cannot mutate > > the local symbol table of the callee (as far as I’m aware). > > > > Any thoughts? > > > > Regards > > > > > >
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
On Sep 15, 2017 11:22 AM, wrote: Hi! The `extract` function takes an associative array and puts it into the local symbol table. http://php.net/manual/en/function.extract.php ``` $array = [ ‘foo’ => ‘foo’, ‘bar’ => ‘bar’, ]; extract($array); print $foo; // "foo" ``` As a second parameter the `extract` function takes some options to make this function less dangerous, like `EXTR_SKIP` that prevents an existing local variable of being overwritten. There’s a few more options, go ahead and take a look at the documentation. `EXTR_OVERWRITE` is the default one though. You can also pass a prefix for the variable names as a third argument. I seriously doubt the usefulness of this function, especially looking at the potential risks. The fact that overwriting the local variables is the default behaviour doesn’t make it any better. I suggest deprecating it in PHP 7.3 and removing it in 8. In a whole Symfony-Stack (3.4) with all of it’s dependencies I could only find two usages of this function, both of which could be easily rewritten in vanilla PHP: https://github.com/symfony/symfony/blob/master/src/ Symfony/Component/Templating/PhpEngine.php#L148 https://github.com/symfony/symfony/blob/master/src/ Symfony/Component/Templating/PhpEngine.php#L158 Only downside: A polyfill is probably impossible since you cannot mutate the local symbol table of the callee (as far as I’m aware). Any thoughts? I see no gain by removing this function. I've also seen it used for templating quite often. Yes the functionality could be changed not to use extract and end up working the same to the consumer but why make people rewrite these things for no apparent gain (and likely a small performance hit)? Regards
Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Heya, This is typically used in templating engines. The one I worked on is https://github.com/zendframework/zend-view/blob/5523511b6771cb6c060a77f6777426526a8db5ab/src/Renderer/PhpRenderer.php#L491-L492 Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Fri, Sep 15, 2017 at 7:20 PM, wrote: > Hi! > > The `extract` function takes an associative array and puts it into the > local symbol table. > http://php.net/manual/en/function.extract.php > > ``` > $array = [ > ‘foo’ => ‘foo’, > ‘bar’ => ‘bar’, > ]; > > extract($array); > > print $foo; // "foo" > ``` > > As a second parameter the `extract` function takes some options to make > this function less dangerous, like `EXTR_SKIP` that prevents an existing > local variable of being overwritten. There’s a few more options, go ahead > and take a look at the documentation. `EXTR_OVERWRITE` is the default one > though. You can also pass a prefix for the variable names as a third > argument. > > I seriously doubt the usefulness of this function, especially looking at > the potential risks. The fact that overwriting the local variables is the > default behaviour doesn’t make it any better. I suggest deprecating it in > PHP 7.3 and removing it in 8. > > In a whole Symfony-Stack (3.4) with all of it’s dependencies I could only > find two usages of this function, both of which could be easily rewritten > in vanilla PHP: > https://github.com/symfony/symfony/blob/master/src/ > Symfony/Component/Templating/PhpEngine.php#L148 > https://github.com/symfony/symfony/blob/master/src/ > Symfony/Component/Templating/PhpEngine.php#L158 > > Only downside: A polyfill is probably impossible since you cannot mutate > the local symbol table of the callee (as far as I’m aware). > > Any thoughts? > > Regards > > >
[PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3
Hi! The `extract` function takes an associative array and puts it into the local symbol table. http://php.net/manual/en/function.extract.php ``` $array = [ ‘foo’ => ‘foo’, ‘bar’ => ‘bar’, ]; extract($array); print $foo; // "foo" ``` As a second parameter the `extract` function takes some options to make this function less dangerous, like `EXTR_SKIP` that prevents an existing local variable of being overwritten. There’s a few more options, go ahead and take a look at the documentation. `EXTR_OVERWRITE` is the default one though. You can also pass a prefix for the variable names as a third argument. I seriously doubt the usefulness of this function, especially looking at the potential risks. The fact that overwriting the local variables is the default behaviour doesn’t make it any better. I suggest deprecating it in PHP 7.3 and removing it in 8. In a whole Symfony-Stack (3.4) with all of it’s dependencies I could only find two usages of this function, both of which could be easily rewritten in vanilla PHP: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Templating/PhpEngine.php#L148 https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Templating/PhpEngine.php#L158 Only downside: A polyfill is probably impossible since you cannot mutate the local symbol table of the callee (as far as I’m aware). Any thoughts? Regards
Re: [PHP-DEV] [VOTE] UUID
> > Richard, > > The minimal voting period is actually just one week, so as far as the > Voting RFC requirements are concerned, you can close it right now. If you > want to stick to the Sep 16 deadline you announced at the beginning of the > vote, someone else can close the poll, Sep 16 is just hours away. > Respectfully, it doesn't make sense to prolong it just because you don't > have Internet access (plus, it's easy enough to work with wiki.php.net on > 3G/mobile, from experience...) > > Zeev > If it's closed a few days later, it doesn't matter either. Regards, Niklas
RE: [PHP-DEV] [VOTE] UUID
Richard, The minimal voting period is actually just one week, so as far as the Voting RFC requirements are concerned, you can close it right now. If you want to stick to the Sep 16 deadline you announced at the beginning of the vote, someone else can close the poll, Sep 16 is just hours away. Respectfully, it doesn't make sense to prolong it just because you don't have Internet access (plus, it's easy enough to work with wiki.php.net on 3G/mobile, from experience...) Zeev -Original Message- From: Fleshgrinder [mailto:p...@fleshgrinder.com] Sent: Friday, September 15, 2017 7:00 PM To: Stanislav Malyshev ; internals@lists.php.net Subject: Re: [PHP-DEV] [VOTE] UUID On 9/6/2017 9:56 PM, Stanislav Malyshev wrote: > BTW, the RFC text does not have vote end date, please add it. > Done, had to move that to Wednesday, because I won't have Internet access until then. Closing it today would mean that the min of 2 weeks voting would not be achieved. -- Richard "Fleshgrinder" Fussenegger
Re: [PHP-DEV] [VOTE] UUID
On 9/6/2017 9:56 PM, Stanislav Malyshev wrote: > BTW, the RFC text does not have vote end date, please add it. > Done, had to move that to Wednesday, because I won't have Internet access until then. Closing it today would mean that the min of 2 weeks voting would not be achieved. -- Richard "Fleshgrinder" Fussenegger signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
Am 15.09.2017 um 16:58 schrieb Tony Marston: wrote in message news:5fe274c1-36de-e650-fd2c-bc4f9caf3...@rhsoft.net... Am 15.09.2017 um 11:25 schrieb Tony Marston: You are missing a third option - Microsoft languages are case-preserving. This is where the IDE ensures that every use of a word is automatically switched to the case used in its original definition. This makes it impossible to use the same word with a different case. a sane IDE for PHP does exactly the same for many many years if you don't insist to change it manually - when you manage that you functions are written all over your codebase with different uppercase/lowercase the problem is looking at you from a mirror every morning How many IDEs out there for PHP? What percentage of them support case preserving? Zend Studio didn't when I used it. PHPEd doesn't i need to see one which don't make autocompletion with preserved case and if you don't use it because you like typos in general your fault again: it's no rocket science to throw at compile time deprecation warnings years before a final change is planned and so for sloppy legacy code you hav enot more to do than read your error logs after i switched every piece of code i write the last 15 years tpo strict-types, typhe-hints and return-types everywhere while also write a complete autotest suite you can't tell me it costs more time to fix such case warnings by read the log and it would take longer as all your discussions - so why don't you stop it? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:5fe274c1-36de-e650-fd2c-bc4f9caf3...@rhsoft.net... Am 15.09.2017 um 11:25 schrieb Tony Marston: You are missing a third option - Microsoft languages are case-preserving. This is where the IDE ensures that every use of a word is automatically switched to the case used in its original definition. This makes it impossible to use the same word with a different case. a sane IDE for PHP does exactly the same for many many years if you don't insist to change it manually - when you manage that you functions are written all over your codebase with different uppercase/lowercase the problem is looking at you from a mirror every morning How many IDEs out there for PHP? What percentage of them support case preserving? Zend Studio didn't when I used it. PHPEd doesn't. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Lester Caine" wrote in message news:55603872-e832-65ea-25b6-48e01074a...@lsces.co.uk... On 15/09/17 10:02, Tony Marston wrote: Why is it not possible to identify a single upper and lower case variant for every character in every character set? Can't find the right unicode standard page, but https://www.elastic.co/guide/en/elasticsearch/guide/current/case-folding.html sums it up. Try this page: http://unicode.org/faq/casemap_charprop.html Notice that case folding for case insensitive comparisons is relatively easy when compared with case switching. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Lester Caine" wrote in message news:d97cd2e5-bd5b-4c9f-2c20-107560d5a...@lsces.co.uk... On 15/09/17 12:13, Tony Marston wrote: My argument is that far too many people have become used to case insensitive software, and to remove this "feature" for no other reason than the programmers involved would find it "more convenient" to remove the feature altogether rather than make the effort in implementing a proper solution would go down like a ton of bricks with all those users. case-insensitive only works reliably for an ascii character set. This is what the vast majority of PROGRAMMERS expect to see. Even Microsoft 16bit subset of unicode characters can not RELIABLY be upper or lower cased, but add the full unicode set and the conflicts of the number of characters required for one or other conversion explains why a conversion to unicode in the core proved impractical. It may be impractical for lazy programmers, but it is not impossible. While unicode can comfortably deal with one-to-one case mappings, it does provide the means to specify one-to-many case mappings and other special cases. All it needs is for all these special cases to be identified and the "problem" is alleviated. The main point here is that it may be ESSENTIAL to introduce a switch to case sensitive if we are also to convert to full unicode support. The alternative is to restrict the character set back to ascii for all programming operations if case-insensitivity is to be retained. Good idea. If certain characters cause problems when switching case then those characters should be banned. And how many of you have hit the problem of Windows supplying a CamelCase version of a file name when it was entered lower case. I haven't, but I always take the precaution of downshifting all file names in order to avoid problems with that PITA called unix/linux. Since all our web servers are 'non-windows', hitting the idiosyncrasies of these inappropriate case conversions just adds to the fun. That may not the happening these days, but cause major problems at one time! There are still inconsistencies when different browsers render the same HTML, CSS or Javascript differently. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
Am 15.09.2017 um 16:38 schrieb Tony Marston: wrote in message news:8bbcc1fc-0d13-27d4-a04f-0a5ebda4c...@rhsoft.net... Am 15.09.2017 um 11:12 schrieb Tony Marston: I am not asking the world to slow down because I am too lazy to change. I am arguing that case insensitive software has been around for many decades, and for some people to advocate for its removal just because they don't have the brain power to come up with a proper solution for a minor glitch that affects only a small number of languages I find unacceptable. A competent programmer would fix the problem that affects the few without removing a feature that the many are used to and a competent programmer using PHP as programming language would not define a funtion do_something() and write "Do_Something", "do_Something", "DO_something" all over his codebase While that may be "uncool" or even "inconsistent" it does not cause a genuine problem. But you seem to be supporting a change which would be worse than uncool, it would be downright horrific. No human language that I know of allows a word to change its meaning just by changing the case of one or more characters i brought you samples of german where the meanining of the same word changes *dramatically* - "nett zu Vögeln" versus "nett zu vögeln" which goes from "nice to birds" to "nice to fuck" and this standard behaviour was echoed in all the computer systems that I have used since the 1970s. The fact that I can create a function called do_something() and later refer to it as either Do_something(), do_Something() or even Do_SomeThing() may be annoying but it is irrelevant. Do you realise how many problems it would cause if each change in case pointed to a totally different function? only when one is so short-sighted as you act it's not rocket science at compile time throw a error that you are not allowed to define foo() and Foo() in the same software which has no runtime costs and after that you may even have less runtime costs because all the case-insensitive handling can be skipped and well, for the time of deprecation the compiler code with finally throws errors can issue the warnings with file and line - i assure you that going to fix that warnings takes less time than the whole discussion with you over the last days from several people Would you support anyone who proposed adding a series of functions to PHP core or an extension where every function used exactly the same words but in a different case? see above - just because you assume it's rocket scienece doesn't mean it is -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
wrote in message news:8bbcc1fc-0d13-27d4-a04f-0a5ebda4c...@rhsoft.net... Am 15.09.2017 um 11:12 schrieb Tony Marston: I am not asking the world to slow down because I am too lazy to change. I am arguing that case insensitive software has been around for many decades, and for some people to advocate for its removal just because they don't have the brain power to come up with a proper solution for a minor glitch that affects only a small number of languages I find unacceptable. A competent programmer would fix the problem that affects the few without removing a feature that the many are used to and a competent programmer using PHP as programming language would not define a funtion do_something() and write "Do_Something", "do_Something", "DO_something" all over his codebase While that may be "uncool" or even "inconsistent" it does not cause a genuine problem. But you seem to be supporting a change which would be worse than uncool, it would be downright horrific. No human language that I know of allows a word to change its meaning just by changing the case of one or more characters, and this standard behaviour was echoed in all the computer systems that I have used since the 1970s. The fact that I can create a function called do_something() and later refer to it as either Do_something(), do_Something() or even Do_SomeThing() may be annoying but it is irrelevant. Do you realise how many problems it would cause if each change in case pointed to a totally different function? Would you support anyone who proposed adding a series of functions to PHP core or an extension where every function used exactly the same words but in a different case? What will happen in the future if we move away from keyboard input towards speech input? It will not be good enough to simply say a word, you would have to spell it out character by character and specify the case of each character. Do you think that would be a good idea? the problem which makes such a change dramatic is the poor code quality of most projects and as i remeber you even fighted some months ago that a consistent coding style within a project is nothing you care about and that explains how you argue here very well I'm afraid that changing the way I do things just to be "consistent" with others is not a good argument when it ends up being "consistently bad". Weitergeleitete Nachricht Betreff: Re: [PHP-DEV] Class Naming in Core Datum: Mon, 5 Jun 2017 09:14:47 +0100 Von: Tony Marston An: internals@lists.php.net Seriously, can you explain in words of one syllable the precise benefits of such a consistency? Can you measure the benefits? Just because some OCD sufferers like consistency is not a good enough reason. I have been programming for over 30 years, and in that time I have had to deal with both snake_case and CamelCase, and while I personally find that snake_case is more readable, especially with names that contain more than 3 or 4 words, I have no trouble reading either. Having a mixture of styles does not cause a problem (except in the minds of OCD sufferers) so IMHO it does not require a solution. Anybody who says that they cannot work with a mixture of naming styles is either a liar or Illiterate. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
Am 15.09.2017 um 16:15 schrieb Tony Marston: Can you show me any language where a single character has multiple alternatives when switching case? http://cdn.webfail.com/upl/img/07181c2ca27/post2.jpg _ german: Sie ist wirklich gut zu Vögeln english: she is really nice to birds german: Sie ist wirkich gut zu vögeln english: she is really nice to fuck _ german: Ich wünschte er wäre Dichter! english: i wish he would be a poet german: Ich ünschte er wäre dichter! english: i wish he would be more drunken _ and now stop it! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Alain Williams" wrote in message news:20170915093457.gi8...@phcomp.co.uk... On Fri, Sep 15, 2017 at 09:51:53AM +0100, Tony Marston wrote: >Iike how you map lower -> upper depends on how you encode characters. Then use a single UNICODE character set where every character has both an upper and lower case representation. Problem solved. Not possible - see below. I don't give two hoots what javascript does. Many PHP programmers also write Javascript. Avoiding gratuitous inconsistencies will help them. UNICODE was supposedly invented to deal with all these problems so why doesn't it? Why is it not possible to define an uppercase and lowercase variant of the same character? I don't think that you understand Unicode. Case mapping is not as simple as you seem to think - even in English. For a start there are 3 cases: lower, upper & title. It then gets more complicated. I suggest that you read: http://unicode.org/faq/casemap_charprop.html I have read that article, and while it says that case switching may not be easy it does not say that it is impossible. While most case mappings work on a one-to-one basis it is possible to specify any one-to-any mappings as well as any additional mappings used in case folding for any exceptions. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Alain Williams" wrote in message news:20170915092114.gh8...@phcomp.co.uk... On Fri, Sep 15, 2017 at 10:04:51AM +0100, Tony Marston wrote: >The light bulb was invented by an English man (Joseph Swan), the >television by a >Scott (John Logie Baird); so should the Brits and Scots be the >ones that define >light bulb and TV standards to suit their convenience ? > Don't be silly. Neither light bulbs nor television sets are affected by which case is used in which character set. >>Because the English-speaking world invented both computers and the >>languages used to program them. > >It was a German that invented binary, so my suggestion is to devolve all >future decisions to the Germans. Binary coding is not affected by changes in case so this argument is bogus. I think that both Rowan Collins & I agree on that point. We were commenting on your assertion: >>Because the English-speaking world invented both computers and the >>languages used to program them. > Thus because we are English speaking we do not have a special position to dictate the development of computers and languages -- especially as it affects non-English speakers. You are missing the point. The convention in the whole of the English-speaking world is exactly the same - it has both upper and lower case characters, and the meaning of a word does not change simply because some characters are written in a different case. When a person searches for a word in a dictionary he is not bothered about case. When a person searches for a file in the Windows OS he is not bothered about case. When a person searches for a word inside a file he is not bothered about case. I has seen some search mechanisms which provide the option to make the search case sensitive, but that is an option which has to be turned on - the default is still case insensitive. Can you show me any dictionary in ANY language where the same word has different meanings just by changing the case of one or more characters? Can you show me any language where a single character has multiple alternatives when switching case? By my reckoning case insensitivity has been the default way before computers were invented, and all the software on the early computers was also case insensitive. I have worked on numerous hardware platforms since the 1970s, and they were ALL case insensitive. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
On 15.09.2017 at 01:34, Stanislav Malyshev wrote:
>> > define('FOO', true, true); // public const in ext; transcript from C
>> const FOO = false; // in global app code
>>
>> Why doesn't that fail? How am I supposed to write the extension
>
> It should fail, but that's not what we're discussing here.
I think it is, see .
> If you say that everybody already used CONST_CS then great. I
> see however that some extensions (e.g. ibase and mcrypt) do not use that
> flag.
Thanks for pointing out my mistake. I had a closer look and indeed
found that ext/interbase defines case-insensitive constants throughout.
The only other case-insensitive constants defined in a recent php-src
master seem to be TRUE, FALSE, NULL and SID.
With regard to mcrypt and interbase: the former has been deprecated as
of PHP 7.1.0[1], and the latter had originally been suggested for
removal as of PHP 7.0.0, but a maintainer stepped forward and so the
extension has been kept, but apparently they don't have the time to
maintain the extension anymore[2]. It seems to me that users of these
extensions have bigger issues than changing the case of the constants
(if this would even be necessary; they may well already have written
these in upper case).
And of course, there may be many more extensions defining
case-insensitive constants, and it appears to be practically impossible
to assess the resulting BC break if we remove this option. However, I'm
not suggesting to remove it right away, but rather to deprecate
case-insensitive constants first. Any peace of software that is
actively maintained should be able to cope with this change during the
course of some years.
Anyhow, sticking with the possibility to define case-insensitive
constants in extensions, but to remove the third parameter of define()
wouldn't help at all.
[1]
[2]
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
On 15/09/17 10:02, Tony Marston wrote: > Why is it not possible to identify a single upper and lower case variant > for every character in every character set? Can't find the right unicode standard page, but https://www.elastic.co/guide/en/elasticsearch/guide/current/case-folding.html sums it up. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
On 15/09/17 12:13, Tony Marston wrote: > My argument is that far too many people have become used to case > insensitive software, and to remove this "feature" for no other reason > than the programmers involved would find it "more convenient" to remove > the feature altogether rather than make the effort in implementing a > proper solution would go down like a ton of bricks with all those users. case-insensitive only works reliably for an ascii character set. This is what the vast majority of PROGRAMMERS expect to see. Even Microsoft 16bit subset of unicode characters can not RELIABLY be upper or lower cased, but add the full unicode set and the conflicts of the number of characters required for one or other conversion explains why a conversion to unicode in the core proved impractical. The main point here is that it may be ESSENTIAL to introduce a switch to case sensitive if we are also to convert to full unicode support. The alternative is to restrict the character set back to ascii for all programming operations if case-insensitivity is to be retained. And how many of you have hit the problem of Windows supplying a CamelCase version of a file name when it was entered lower case. Since all our web servers are 'non-windows', hitting the idiosyncrasies of these inappropriate case conversions just adds to the fun. That may not the happening these days, but cause major problems at one time! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Andrey Andreev" wrote in message news:CAPhkiZxdVwiEDOW9XZfcADV+o1UC=sg_pc2nw7nqu1w_gv8...@mail.gmail.com... Hi again, On Fri, Sep 15, 2017 at 12:46 PM, Tony Marston wrote: "Andrey Andreev" wrote in message news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0...@mail.gmail.com... Hi, On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston wrote: Far better that that problem is taken away from the file system (which should be clean, robust and fast) and if you want case independence put it up at the application layer. You try telling that to the billions of Windows users who have been used to a case insensitive file system for decades. Not to mention all Microsoft software which is case insensitive. Try to take that away and billions of users will be baying for your blood. Billions? Do we have that statistic available? How many people in the world work with PCs running Microsoft Windows? More than those running alternatives. So you admit that you just made up the number? Can you show me any statistics which prove otherwise? And how many of them have ever encountered case-sensitivity as a concept? None, because they have always used case-insensitive software. And that will not change, regardless of how PHP constants work. Thus, re-inforcing my point - that you're completely off-topic. Do they all manually type-in filenames that they want to open? If so, do they for some reason name their files in all upper-case, but then type in lower-case while opening? When searching for a file in Windows it is not necessary to now what case it was created in. When searching for a word in a file it is not necessary to now what case it was created in. TRy taking that ability away from Windows users and see what reaction you get. 1. Search is a feature that goes way beyond case-sensitivity, and that was not what I was (rhetorically) asking. 2. Unless Windows users search for filenames matching constants declared in PHP code, this is irrelevant. Also, are we Microsoft developers? Are we trying to change Windows? No, but you are suggesting a change from being consistent with Windows to being inconsistent. It *happens* to be consistent; nobody has ever cared about whether it is or not. And I am not suggesting anything. I am simply pointing out the ridiculous false-equivalences you're making. And most importantly: How do everyday Windows users have anything to do with PHP developers? Some people are also Windows users as well as PHP developers, and if those people are told that some of the software which they use is now being switched from being case-insensitive to case-sensitive just because the programmers cannot solve a small problem which only affects a small number of character sets, then those people will not be happy. Case-insensitive software has been around for decades and is regarded by many users as a feature. It that "feature" is broken in a small number of cases then a proper programmer would fix that broken feature and not advocate for its removal just because it is more convenient than developing a fix. You do realize you just went from comparing "billions" and how supposedly an overwhelming majority would be upset, to "some people". And even within that intersection of audiences, you would never be able to convince anybody here, that for some reason John Doe would declare a constant as FOO, but then use it as Foo. I believe I've made my point. Please stop with the non-sense comparisons, and talk about *constants in PHP*. You may think that this issue is limited to constants but others do not. Someone (not me) said that if constants were to be made case sensitive then the rest of the language should follow suit "just to be consistent". Someone else (not me) pointed to a bug regarding case switching when using the Turkish character set. It was suggested that one way to resolve this issue would be to avoid case switching altogether by making everything case sensitive. I suggest you look at Levi Morrison's post dated 14/09/2017 @ 17:02 which said: "For what it is worth the Turkish locale issue is on-topic. If we have case sensitivity and case insensitivity simultaneously in constants and we decide to drop one then the locale issue points towards dropping case insensitivity." My argument is that far too many people have become used to case insensitive software, and to remove this "feature" for no other reason than the programmers involved would find it "more convenient" to remove the feature altogether rather than make the effort in implementing a proper solution would go down like a ton of bricks with all those users. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
Hi again, On Fri, Sep 15, 2017 at 12:46 PM, Tony Marston wrote: > "Andrey Andreev" wrote in message > news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0...@mail.gmail.com... >> >> >> Hi, >> >> On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston >> wrote: >>> >>> Far better that that problem is taken away from the file system (which should be clean, robust and fast) and if you want case independence put it up at the application layer. >>> >>> >>> >>> You try telling that to the billions of Windows users who have been used >>> to >>> a case insensitive file system for decades. Not to mention all Microsoft >>> software which is case insensitive. Try to take that away and billions of >>> users will be baying for your blood. >>> >> >> Billions? Do we have that statistic available? > > > How many people in the world work with PCs running Microsoft Windows? More > than those running alternatives. > So you admit that you just made up the number? >> And how many of them have ever encountered case-sensitivity as a concept? > > > None, because they have always used case-insensitive software. > And that will not change, regardless of how PHP constants work. Thus, re-inforcing my point - that you're completely off-topic. >> Do they all manually type-in filenames that they want to open? If so, >> do they for some reason name their files in all upper-case, but then >> type in lower-case while opening? > > > When searching for a file in Windows it is not necessary to now what case it > was created in. When searching for a word in a file it is not necessary to > now what case it was created in. TRy taking that ability away from Windows > users and see what reaction you get. > 1. Search is a feature that goes way beyond case-sensitivity, and that was not what I was (rhetorically) asking. 2. Unless Windows users search for filenames matching constants declared in PHP code, this is irrelevant. >> Also, are we Microsoft developers? Are we trying to change Windows? > > > No, but you are suggesting a change from being consistent with Windows to > being inconsistent. > It *happens* to be consistent; nobody has ever cared about whether it is or not. And I am not suggesting anything. I am simply pointing out the ridiculous false-equivalences you're making. >> And most importantly: How do everyday Windows users have anything to >> do with PHP developers? > > > Some people are also Windows users as well as PHP developers, and if those > people are told that some of the software which they use is now being > switched from being case-insensitive to case-sensitive just because the > programmers cannot solve a small problem which only affects a small number > of character sets, then those people will not be happy. Case-insensitive > software has been around for decades and is regarded by many users as a > feature. It that "feature" is broken in a small number of cases then a > proper programmer would fix that broken feature and not advocate for its > removal just because it is more convenient than developing a fix. > You do realize you just went from comparing "billions" and how supposedly an overwhelming majority would be upset, to "some people". And even within that intersection of audiences, you would never be able to convince anybody here, that for some reason John Doe would declare a constant as FOO, but then use it as Foo. I believe I've made my point. Please stop with the non-sense comparisons, and talk about *constants in PHP*. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
Am 15.09.2017 um 11:25 schrieb Tony Marston: You are missing a third option - Microsoft languages are case-preserving. This is where the IDE ensures that every use of a word is automatically switched to the case used in its original definition. This makes it impossible to use the same word with a different case. a sane IDE for PHP does exactly the same for many many years if you don't insist to change it manually - when you manage that you functions are written all over your codebase with different uppercase/lowercase the problem is looking at you from a mirror every morning -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
Am 15.09.2017 um 11:12 schrieb Tony Marston: I am not asking the world to slow down because I am too lazy to change. I am arguing that case insensitive software has been around for many decades, and for some people to advocate for its removal just because they don't have the brain power to come up with a proper solution for a minor glitch that affects only a small number of languages I find unacceptable. A competent programmer would fix the problem that affects the few without removing a feature that the many are used to and a competent programmer using PHP as programming language would not define a funtion do_something() and write "Do_Something", "do_Something", "DO_something" all over his codebase the problem which makes such a change dramatic is the poor code quality of most projects and as i remeber you even fighted some months ago that a consistent coding style within a project is nothing you care about and that explains how you argue here very well Weitergeleitete Nachricht Betreff: Re: [PHP-DEV] Class Naming in Core Datum: Mon, 5 Jun 2017 09:14:47 +0100 Von: Tony Marston An: internals@lists.php.net Seriously, can you explain in words of one syllable the precise benefits of such a consistency? Can you measure the benefits? Just because some OCD sufferers like consistency is not a good enough reason. I have been programming for over 30 years, and in that time I have had to deal with both snake_case and CamelCase, and while I personally find that snake_case is more readable, especially with names that contain more than 3 or 4 words, I have no trouble reading either. Having a mixture of styles does not cause a problem (except in the minds of OCD sufferers) so IMHO it does not require a solution. Anybody who says that they cannot work with a mixture of naming styles is either a liar or Illiterate. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Andrey Andreev" wrote in message news:CAPhkiZyXgxi-7vWdqA2hxni9SvycuN_pWOOM8un8mUo5qJ=0...@mail.gmail.com... Hi, On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston wrote: Far better that that problem is taken away from the file system (which should be clean, robust and fast) and if you want case independence put it up at the application layer. You try telling that to the billions of Windows users who have been used to a case insensitive file system for decades. Not to mention all Microsoft software which is case insensitive. Try to take that away and billions of users will be baying for your blood. Billions? Do we have that statistic available? How many people in the world work with PCs running Microsoft Windows? More than those running alternatives. And how many of them have ever encountered case-sensitivity as a concept? None, because they have always used case-insensitive software. Do they all manually type-in filenames that they want to open? If so, do they for some reason name their files in all upper-case, but then type in lower-case while opening? When searching for a file in Windows it is not necessary to now what case it was created in. When searching for a word in a file it is not necessary to now what case it was created in. TRy taking that ability away from Windows users and see what reaction you get. Also, are we Microsoft developers? Are we trying to change Windows? No, but you are suggesting a change from being consistent with Windows to being inconsistent. And most importantly: How do everyday Windows users have anything to do with PHP developers? Some people are also Windows users as well as PHP developers, and if those people are told that some of the software which they use is now being switched from being case-insensitive to case-sensitive just because the programmers cannot solve a small problem which only affects a small number of character sets, then those people will not be happy. Case-insensitive software has been around for decades and is regarded by many users as a feature. It that "feature" is broken in a small number of cases then a proper programmer would fix that broken feature and not advocate for its removal just because it is more convenient than developing a fix. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
On Fri, Sep 15, 2017 at 09:51:53AM +0100, Tony Marston wrote: > >Iike how you map lower -> upper depends on how you encode characters. > > Then use a single UNICODE character set where every character has > both an upper and lower case representation. Problem solved. Not possible - see below. > I don't give two hoots what javascript does. Many PHP programmers also write Javascript. Avoiding gratuitous inconsistencies will help them. > UNICODE was supposedly invented to deal with all these problems so > why doesn't it? Why is it not possible to define an uppercase and > lowercase variant of the same character? I don't think that you understand Unicode. Case mapping is not as simple as you seem to think - even in English. For a start there are 3 cases: lower, upper & title. It then gets more complicated. I suggest that you read: http://unicode.org/faq/casemap_charprop.html -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
""Christoph M. Becker"" wrote in message news:320b3863-e36b-2ed4-543b-fcbd433b1...@gmx.de... On 14.09.2017 at 23:22, Stanislav Malyshev wrote: [Nikita wrote] +1 on doing this. I can understand having case-insensitive constants, but having both case-sensitive and case-insensitive at the same time is weird and rather useless. I imagine the only reason why this "feature" exists in the first place is to support arbitrary casing for true/false/null, which is better handled by special-casing these particular constants (something we already do for various other reasons). This will simplify the language If we support all case-insensitive constants that are predefined (not sure if any exts do that but we have to support those too if they do) then I don't see a big problem in phasing-out user-defined ones. It seems to me that this would miss the point, namely to introduce some consistency, and to be able to [Nikita continued] reduce implementation complexity on our side and resolve some bugs that are infeasible to fix otherwise. All programming languages that I know of are either case-sensitive or case-insensitive. You are missing a third option - Microsoft languages are case-preserving. This is where the IDE ensures that every use of a word is automatically switched to the case used in its original definition. This makes it impossible to use the same word with a different case. PHP is the sole execption (CMIIW) – and the potential cognitive overhead during programming is hard to justify. Constants are the icing on the cake: they can be either case-insensitive or case-sensitive at the discression of the dev defining the constant. Using an extension which defines case-insensitive constants might raise the following issue: Although the PHP manual says that constants are case-insensitive, it also says that by convention all constants are uppercase. I have been following that convention, so a change to make constants case sensitive instead of insensitive would not bother me. In fact it would not bother me if user-defined constants could only ever be in upper case as that would remove any possible confusion between 'foo' and 'Foo'. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
On Fri, Sep 15, 2017 at 10:04:51AM +0100, Tony Marston wrote: > >The light bulb was invented by an English man (Joseph Swan), the > >television by a > >Scott (John Logie Baird); so should the Brits and Scots be the > >ones that define > >light bulb and TV standards to suit their convenience ? > > > > Don't be silly. Neither light bulbs nor television sets are affected > by which case is used in which character set. > >>Because the English-speaking world invented both computers and the > >>languages used to program them. > > > >It was a German that invented binary, so my suggestion is to devolve all > >future decisions to the Germans. > > Binary coding is not affected by changes in case so this argument is bogus. I think that both Rowan Collins & I agree on that point. We were commenting on your assertion: > >>Because the English-speaking world invented both computers and the > >>languages used to program them. > > Thus because we are English speaking we do not have a special position to dictate the development of computers and languages -- especially as it affects non-English speakers. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
Hi, On Fri, Sep 15, 2017 at 11:51 AM, Tony Marston wrote: > >> Far better that that >> problem is taken away from the file system (which should be clean, robust >> and >> fast) and if you want case independence put it up at the application >> layer. > > > You try telling that to the billions of Windows users who have been used to > a case insensitive file system for decades. Not to mention all Microsoft > software which is case insensitive. Try to take that away and billions of > users will be baying for your blood. > Billions? Do we have that statistic available? And how many of them have ever encountered case-sensitivity as a concept? Do they all manually type-in filenames that they want to open? If so, do they for some reason name their files in all upper-case, but then type in lower-case while opening? Also, are we Microsoft developers? Are we trying to change Windows? And most importantly: How do everyday Windows users have anything to do with PHP developers? Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Daniel Morris" wrote in message news:1505397937.4137791.1106049000.16b88...@webmail.messagingengine.com... On Thu, 14 Sep 2017, at 02:48 PM, Tony Marston wrote: Because the English-speaking world invented both computers and the languages used to program them. It was a German that invented binary, so my suggestion is to devolve all future decisions to the Germans. Binary coding is not affected by changes in case so this argument is bogus. On Thu, 14 Sep 2017, at 02:36 PM, Tony Marston wrote: The number of people in the world who use character sets which do not have this problem far outnumber those who use character sets which do have this problem. People without this problem far outnumber the others, so it would not be a good idea to inconvenience the many just to satisfy the few. You are nearly always a minority opinion, the irony of you writing this whilst at the same time asking the world to slow down so that your stubborn fourteen year old framework can catch up beggars belief. I am not asking the world to slow down because I am too lazy to change. I am arguing that case insensitive software has been around for many decades, and for some people to advocate for its removal just because they don't have the brain power to come up with a proper solution for a minor glitch that affects only a small number of languages I find unacceptable. A competent programmer would fix the problem that affects the few without removing a feature that the many are used to. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Alain Williams" wrote in message news:20170914135519.gw8...@phcomp.co.uk... On Thu, Sep 14, 2017 at 02:48:06PM +0100, Tony Marston wrote: "Rowan Collins" wrote in message news:7394e3ce-b05a-474e-8ab5-a651fdd35...@gmail.com... > >On 14 September 2017 13:59:20 BST, Tony Marston > wrote: >>Why should the >>English-speaking world be forced to suffer just because some minor >>languages >>cannot handle case folding? > >Have you any idea how arrogant this sounds? Why should "the >English-speaking world" get to make up the rules? What criteria >make something "a minor language"? Who gave you the right to make >such lofty pronouncements? Because the English-speaking world invented both computers and the languages used to program them. The light bulb was invented by an English man (Joseph Swan), the television by a Scott (John Logie Baird); so should the Brits and Scots be the ones that define light bulb and TV standards to suit their convenience ? Don't be silly. Neither light bulbs nor television sets are affected by which case is used in which character set. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Alain Williams" wrote in message news:20170914134603.gs8...@phcomp.co.uk... On Thu, Sep 14, 2017 at 02:36:27PM +0100, Tony Marston wrote: ""Christoph M. Becker"" wrote in message news:98ab178e-b999-7e36-5ff5-7b8c28fe0...@gmx.de... > >On 14.09.2017 at 14:59, Tony Marston wrote: > >>Introducing case sensitivity into what is mostly a case-insensitive >>world just for the convenience of a few programmers I do not consider >>to >>be acceptable. It would cause more problems for far more people than >>the >>insignificant few who insist on using obscure character sets. Why >>should >>the English-speaking world be forced to suffer just because some minor >>languages cannot handle case folding? > >This is not about an "insignificant few who insist on using obscure >character sets", but rather about a language spoken by millions of >people which has to "I" characters, namely dotted and dotless "I". >Rather consistently, the dotless "I"'s lower-case variant is "i", and >the dotted "I"'s lower-case variant is "i". There you go. > The number of people in the world who use character sets which do not have this problem far outnumber those who use character sets which do have this problem. People without this problem far outnumber the others, so it would not be a good idea to inconvenience the many just to satisfy the few. Translation: I do not use these character sets, those who do are not important. Incorrect. The proper question is: How any character sets have this problem? What percentage of the world's computer users are affected by this problem? If this number is quite small then it would be wrong to make the majority suffer just because you don't know how to fix the problem that affects the minority. PHP (& File systems) are best staying away from things like that. Microsoft produces case insensitive software, including file systems, because that is what users are used to. Unix was invented in a laboratory by academics who couldn't develop case insensitive software so they called it a "feature" and not a "bug". Not attempting case folding, and similar, makes it simpler, faster & more robust (not worrying about what sort of 'i' to convert to). It only helps those who do not know what the SHIFT key is for. Why is it not possible to identify a single upper and lower case variant for every character in every character set? -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate and remove case-insensitive constants?
"Alain Williams" wrote in message news:20170914133846.gq8...@phcomp.co.uk... On Thu, Sep 14, 2017 at 02:16:47PM +0100, Tony Marston wrote: A minor detail. Windows followed all the previous OSes which I had used in being case insensitive, which makes unix the odd one out. Besides there are far more computers running Windows than unix, so unixx should not be used as the standard. So you want a return to the horrors of code pages in file systems ? I never said that. Iike how you map lower -> upper depends on how you encode characters. Then use a single UNICODE character set where every character has both an upper and lower case representation. Problem solved. Far better that that problem is taken away from the file system (which should be clean, robust and fast) and if you want case independence put it up at the application layer. You try telling that to the billions of Windows users who have been used to a case insensitive file system for decades. Not to mention all Microsoft software which is case insensitive. Try to take that away and billions of users will be baying for your blood. I vote for making it case sensitive: simpler for the parser; the programmer rapidly learns that it should be 'TRUE' and not 'true' -- job done. This is what Javascript does. I don't give two hoots what javascript does. Many operating systems were case insensitive since your input terminal (eg AR33 Teletype) could only generate one case. But in those days it was simple since you only had one character set: ASCII or EBCDIC (translation of alphabetics between the 2 was easy, some others not so, eg: @"\£#). >But the additional problems that case-insensitive then >introduces may mean that all case-insensitivity has to be removed at >that point? What additional problems? When billions of people are used to living in a case-insensitive world and the only "problems" affect an insignificantly small number in an insignificantly small number of circumstances then the only proper solution is one that solves the problem for the small number without messing it up for the far larger number. That is the sort of mind-set that results in browsers accepting all sort of broken markup and making guesses on what is intended; different browsers make different guesses and render the page differently. The user then blames browser X for getting it wrong rather than the incompetent web developer who can't be bothered to check that their markup is correct. UNICODE was supposedly invented to deal with all these problems so why doesn't it? Why is it not possible to define an uppercase and lowercase variant of the same character? If the problem lies with an incomplete implementation of UNICODE then that is the problem which should be addressed. Any programmer who says that he doesn't have the brain power to provide a proper solution and proposes instead to remove case insensitivity from the entire universe "because it is more convenient" should hang his head in shame. It is the programmer's job to make things easier and more convenient for the user, not for users to accept what is convenient for the programmers to provide. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
