Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78232
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.244 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <5447682B.2080100@sugarcrm.com>
Date: Wed, 22 Oct 2014 19:20:17 +0100
Cc: Dmitry Stogov <dmitry@zend.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <019325A5-4F82-4179-B4D7-29E5649B2616@ajf.me>
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me> <CA+9eiLs9j0XMbtNKSSuqTBhF-BEc1CU__3E4gOhYwuF5zF4_1g@mail.gmail.com> <866A39C7-6F11-408D-8BCA-594BA22E8569@ajf.me> <CA+9eiLutEFyZsJGu9Qk9C7Jd0P48SBXcdRiVyySbqXbEYm3Y3w@mail.gmail.com> <5447682B.2080100@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>,
 Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
From: ajf@ajf.me (Andrea Faulds)


> On 22 Oct 2014, at 09:17, Stas Malyshev <smalyshev@sugarcrm.com> =
wrote:
>=20
> If those are opcodes, those rules will require 2/3 majority for
> acceptance, since those will be the engine rules for type conversion,
> not just a set of functions. And, of course, the rules not matching =
the
> other engine rules for type conversion, sorry for sounding like broken
> record.

No, it wouldn=E2=80=99t require a 2/3 majority. The optimisation me and =
Dmitry are referring to is merely an optimisation, it=E2=80=99s an =
implementation detail. This doesn=E2=80=99t touch any of the language =
spec or the language as understood by users.

Or would you argue that the fact is_long is now an opcode is a language =
change, and Dmitry should=E2=80=99ve made an RFC before making a change =
that is completely non-user-facing?!

> On 22 Oct 2014, at 09:26, Zeev Suraski <zeev@zend.com> wrote:
>=20
> Regardless of how we implement it, this requires a 2/3 majority - =
it'll be
> perceived as an integral part of the core language in the same way =
that
> gettype() and is_array() are considered parts of the core language.

Sure, but so is all of ext/standard really. If you got rid of =
ext/standard, PHP wouldn=E2=80=99t really be PHP. Yet there is no such =
barrier to entry for ext/standard.

> Introducing a new set of typing rules into PHP cannot be a 50%+1 =
decision.

It=E2=80=99s not a =E2=80=9Cnew set of typing rules=E2=80=9D. It=E2=80=99s=
 a set of convenient conversion functions.

Would adding ext/filter have required 2/3 majority? Because it has its =
own set of =E2=80=9Ctyping rules=E2=80=9D.

> On 22 Oct 2014, at 09:34, Zeev Suraski <zeev@zend.com> wrote:
>=20
> Thinking a bit more on this, if we don't want the 2/3 hurdle and =
perhaps
> make this a bit (or actually a lot) less controversial, we should =
change the
> names of these functions.  to_float() strongly implies that this =
function
> represents PHP's standard typing ruleset, which these functions do =
not.

I=E2=80=99m wary of making the names much longer. The less convenient =
they are, the less likely they=E2=80=99ll be used=E2=80=A6 so the less =
likely the primary goal of the RFC would be achieved.

Also, we already have intval, floatval and strval. I think people will =
notice the fact they were introduced in PHP 7 and the fact they=E2=80=99re=
 not aliases of those, and perhaps realise they=E2=80=99re different. If =
they just followed the =E2=80=9Cstandard conversion rules=E2=80=9D, why =
would they exist given the existing functions for that?
--
Andrea Faulds
http://ajf.me/