Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109505
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <CAF+90c-=2RBpVHk2Ri3oeTTMkHN3VjKe4SNG8sXAoFB7vVimYA@mail.gmail.com>
 <d1e87385-d710-4eea-c40e-cc13653a1ba8@gmx.de>
 <CAF+90c94_BxGU49+8qCCy+BWMMBjxe5WsadYORNN7YVQkJ01Bw@mail.gmail.com>
Message-ID: <499ec325-22cd-9cea-aaab-74c9810a9a34@gmx.de>
Date: Thu, 2 Apr 2020 11:53:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c94_BxGU49+8qCCy+BWMMBjxe5WsadYORNN7YVQkJ01Bw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [RFC] Stricter type-checks for arithmetic/bitwise operators
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 02.04.2020 at 10:47, Nikita Popov wrote:

> On Thu, Apr 2, 2020 at 10:35 AM Christoph M. Becker <cmbecker69@gmx.de>
> wrote:
>
>> On 02.04.2020 at 10:14, Nikita Popov wrote:
>>
>>> I would like to propose making the use of arithmetic/bitwise operators=
 on
>>> arrays, resources and (non-overloaded) objects a TypeError exception:
>>>
>>> https://wiki.php.net/rfc/arithmetic_operator_type_checks
>>
>> Thanks!  Generally I like that very much.  I'm not quite sure, though,
>> what to do with resource to int conversions.  These are documented to b=
e
>> valid[1], and are sometimes deliberately used[2], and as such it might
>> be reasonable not to throw on these conversions (maybe even change the
>> current behavior of the ~ operator).
>
> While resource to int conversions are indeed valid, they are not exactly
> commonly used, and if they are used, I would expect an explicit (int) ca=
st
> to be involved. I very seriously doubt that someone writing "$x =3D $y /=
 2"
> really intended this to mean "$x =3D resource_id($y) / 2" -- it is much =
more
> likely that a variable go mixed up. In the unlikely case that that they
> really did intend that, the option of writing "$resourceId =3D (int) $y;=
 $x =3D
> $resourceId / 2" remains, and is much clearer.
>
> On that note, I do wonder whether we should introduce a function like
> get_resource_id(), that makes it more explicit that an (int) cast is
> supposed to fetch a resource ID. This is not a very common operation, an=
d I
> suspect that many PHP programmers may not be familiar with the semantics=
 of
> integer casts on resources. Using get_resource_id($file) would make the
> intent clearer relative to (int) $file. This is similar to the recently
> added get_mangled_object_vars() function, which essentially does the sam=
e
> as (array) $object, but makes it obvious that you really are interested =
in
> mangled properties.

I think something like get_resource_id() would be a good addition.

>> After all, I hope we will be able
>> to port all resources to objects sometime, and till then we could stick
>> with more lax semantics.
>
> I think that's really an argument to align the behavior of resources and
> objects, as it means one less BC break when resources are converted to
> objects. Historically that's something we did in minor versions, so it's
> good to reduce the amount of semantics that change when such a conversio=
n
> is done.

Good point indeed!

So +1 from me on the RFC.  Not absolutely sure about the open questing
regarding going one step further, but tentatively also +1 on that.

Thanks,
Christoph