Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97473
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEbg-4aiz4u5kimrDeXgKT1dd+vtuZOEAUjvkwqkEv44z4cJ4A@mail.gmail.com>
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
 <CAF+90c8+PKJMzD3GM=VJDi5wCWArZhY0r7=sHv4U-wNXTpn7aA@mail.gmail.com>
 <753c3900-0d59-8d0d-3a53-863f42465b49@gmail.com> <CAEbg-4aiz4u5kimrDeXgKT1dd+vtuZOEAUjvkwqkEv44z4cJ4A@mail.gmail.com>
Date: Tue, 27 Dec 2016 14:46:14 +0300
Message-ID: <CAEbg-4Y8p8guZbofQv2chd2XBhv3PLm2f92JaatJrLiKbqrfhw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f403045dd8fc512c7e0544a2669b
Subject: Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.2
From: lisachenko.it@gmail.com (Alexander Lisachenko)

--f403045dd8fc512c7e0544a2669b
Content-Type: text/plain; charset=UTF-8

There was small typo in my previous link to object comparison: new one is
https://3v4l.org/tMokY

2016-12-27 14:33 GMT+03:00 Alexander Lisachenko <lisachenko.it@gmail.com>:

> Hi, internals!
>
> I want to propose to deprecate one more weird feature of PHP called
> "comparison of different types" http://php.net/manual/en/
> language.operators.comparison.php#language.operators.comparison.types.
> Here you can check one simple example https://3v4l.org/kCOAf to see why
> it should be deprecated.
>
> It would be nice to deprecate all comparison operators between different
> types and throw an exception later in future version of PHP.
>
> Operators that should be allowed for comparison of different types are the
> following: ==, !=, ===, !==, <>.
> Operators to deprecate for comparison of different types are the
> following: >, <, >=, <=, <=>
>
> I also think about deprecation of string/object/array comparison with
> operators like greater/less, because it's hard to understand results for
> '1000' < '0xabc1' (see https://3v4l.org/o3iLj) or even object comparison
> https://3v4l.org/5At1l
>
> Thanks!
>
> 2016-12-27 9:52 GMT+03:00 Stanislav Malyshev <smalyshev@gmail.com>:
>
>> Hi!
>>
>> >>     https://wiki.php.net/rfc/deprecations_php_7_2
>>
>> Reading through the list, I find several categories:
>>
>> Completely ok:
>>
>> (unset) - don't see any sane use case anyway
>> gmp_random
>>
>> Can cause breakage but it's ok:
>>
>> $php_errormsg
>> __autoload
>> mbstring.func_overload
>> parse_str() - people can use it in functions, it doesn't have to be
>> globals. But it's cleaner with second arg.
>> $errcontext
>>
>> Don't see a reason to remove:
>>
>> (binary) cast and b"" - yes, they are not currently doing anything. But
>> they don't also hurt anything.
>>
>> High breakage potential:
>>
>> each() - I've seen a lot of code using each. Yes, it's not the best way.
>> A lot of people write code not in absolutely best way but in a way they
>> like to. Argument about list() proposed in RFC makes little sense to me
>> - since problem is with list() and not each() why each() should be
>> deprecated because of it? And I certainly object its removal.
>>
>> create_function() - yes, there are closures now. But there's a lot of
>> code created when there were none, and that code works, and there's no
>> reason to break it. I'd probably be OK with deprecation warning but not
>> with removal.
>>
>> Special case:
>> assert() - if the string arg is a security issue, deprecating it
>> achieves nothing. So I'm not sure I understand the argument for
>> deprecation - if string assert is a problem we probably should make
>> assert() construct instead check if assert is used in eval form, not by
>> argument count?
>>
>> --
>> Stas Malyshev
>> smalyshev@gmail.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>

--f403045dd8fc512c7e0544a2669b--