Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106337
MIME-Version: 1.0
References: <CAF+90c87_Zd07ftVe29=GdjxhxjkFG+VXfm_ZZ3QWqER50QLuA@mail.gmail.com>
 <CAOWwgp=_kR5muoeCHxrs1HveGsiN6y2nz7uas0N-5-K45_CWfA@mail.gmail.com>
In-Reply-To: <CAOWwgp=_kR5muoeCHxrs1HveGsiN6y2nz7uas0N-5-K45_CWfA@mail.gmail.com>
Date: Tue, 30 Jul 2019 09:34:19 +0100
Message-ID: <CALKiJKpDukYSLXkinzEh3wQMxsBQr2mO7W7LHcR+ztQO+yZiig@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009519b1058ee1e0f0"
Subject: Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax
From: rowan.collins@gmail.com (Rowan Collins)

--0000000000009519b1058ee1e0f0
Content-Type: text/plain; charset="UTF-8"

On Tue, 30 Jul 2019 at 07:14, Nicolas Grekas <nicolas.grekas@gmail.com>
wrote:

> I think enough time has passed since php4's call-by-ref for the syntax to
> be
> reused now. I think it's unfair to call the RFC a reminiscent of
> call-by-ref BTW.
>


Firstly, please let's stop calling this a "PHP 4" feature. It was fully
supported right up to 5.2, deprecated in 5.3, and only removed in 5.4.

Secondly, I completely disagree that it's unfair to compare the two. The
syntax being proposed in this RFC (& at both call-site and definition-site)
was supported by versions prior to PHP 5.4. Those versions left it optional
at either side, which was certainly a mistake; but it was perfectly
possible (and probably common) for coding standards to require it in both
locations.

It might be a good idea to include a more thorough discussion of this
history in the RFC.




> About requiring such call-annotations using a "declare" directive it feels
> like a heated topic. But we don't need it, so let's split it appart. I
> could very well see userland tools enforce it at the CS-checking level.
> That would provide 99.999% of the target benefit
>


Unfortunately, it doesn't bring any of the benefits to static analysis that
Nikita is proposing. Indeed, it relies on existing static analysers
correctly finding the function definition to complain whether the optional
& is in place.

Including it as optional would certainly bring some benefit to readers, but
I think it's a lot less than "99.999%" of what making it mandatory would
bring.

Regards,
-- 
Rowan Collins
[IMSoP]

--0000000000009519b1058ee1e0f0--