Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78222
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.174 as permitted sender)
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> 2b3cf64265e54aaaa404198da2b58ded@mail.gmail.com
In-Reply-To: 2b3cf64265e54aaaa404198da2b58ded@mail.gmail.com
MIME-Version: 1.0
Thread-Index: AQJkwG276Wk0Upx97kt7WiAQcULrfAGSwBqnAi5QI8QCGl+NrgJ4wNJWms+AsSCAAAC5AA==
Date: Wed, 22 Oct 2014 11:34:27 +0300
Message-ID: <3a665ef1f9227f6f8b1181575d894b39@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>, Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] [RFC] Safe Casting Functions
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Zeev Suraski [mailto:zeev@zend.com]
> Sent: Wednesday, October 22, 2014 11:26 AM
> To: 'Stas Malyshev'; 'Andrea Faulds'
> Cc: 'PHP Internals'
> Subject: RE: [PHP-DEV] [RFC] Safe Casting Functions
>
> > -----Original Message-----
> > From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
> > Sent: Wednesday, October 22, 2014 11:18 AM
> > To: Dmitry Stogov; Andrea Faulds
> > Cc: PHP Internals
> > Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
> >
> > Hi!
> >
> > >>> - it's probably make sense to implement these function as a new
> > >> opcode(s) in VM
> > >>
> > >> That could be an optimisation later, yes. I note that you=E2=80=99ve=
 added
> > >> function replacement with opcodes for certain commonly-used
> > >> functions. We could make these functions use that. Then they=E2=80=
=99d
> > >> still be usable as callbacks.
> >
> > 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.
>
> Regardless of how we implement it, this requires a 2/3 majority - it'll b=
e
> 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.
> Introducing a new set of typing rules into PHP cannot be a 50%+1 decision=
.

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 th=
e
names of these functions.  to_float() strongly implies that this function
represents PHP's standard typing ruleset, which these functions do not.

If we called them something like lossless_float() - that provides developer=
s
with the necessary heads-up that this will not use the standard conversion
rules they're familiar with.  It also gives them a good indication as to ho=
w
it may be different from those standard rules.

Changing the function names in a way that makes it clear that they don't
represent the standard conversion rules, and providing a good hint as to ho=
w
these functions behave differently right within the function names - would
remove my objection to introducing these functions.  In such a context,
where they're not a part of the perceived core global namespace - I think
they can be considered like any other extension, and be at 50%+1.

Zeev