Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83451
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Lester Caine'" <lester@lsces.co.uk>,
	<internals@lists.php.net>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>	<CAAyV7nHq_-9jyRcwJmiAxthmEo3u3MDXcyOC09LV2DETABzCoA@mail.gmail.com>	<c8b54c9828154c7e07810461db03bd4d@mail.gmail.com> <CALwr1GmzNOFUgZGxC+vRri6btdh=QQaUnE+d0Wr8XLbQOEuMmQ@mail.gmail.com> <54E91123.9010508@lsces.co.uk>
In-Reply-To: <54E91123.9010508@lsces.co.uk>
Date: Sun, 22 Feb 2015 01:07:13 +0100
Message-ID: <066d01d04e33$82dca020$8895e060$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKcPg+jpyYspJS11b5G1A7RBHpKTgFW66vOAVBxp4MBsMGaiwKnqOc8myvmdjA=
Content-Language: fr
Subject: RE: [PHP-DEV] Coercive Scalar Type Hints RFC
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : Lester Caine [mailto:lester@lsces.co.uk]
>
> Fixed length fields may well be a data source so having to strip them
> before using them just seems a backward step. The basic C library =
simply
> strips the white space so are we looking at using an alternative?

I guess you got it wrong : we'll ignore leading and trailing blanks, as =
well as leading 0s. We say we restrict because, where we accepted =
*every* trailing chars, we now only accept blanks. So fixed length =
fields will work as before.

> > 2. Rules don't make mention of leading zeroes, e.g. 0003
> Again data may well be zero padded. This is more likely to be historic
> material, but it's yet another extra processing step. If we have to
> process data before then asking if it's a valid number what is the
> advantage of this? However of cause the C library switches to octal =
mode
> and needs pre processing of leading zero's anyway.

Leading 0s are skipped. Same as PHP 5.
=20
> > 3. "1E07" might be construed as overly generous assuming we are
> > excluding stringy integers like hex, oct and binary
> Yet again ... If we have to add a lot of extra checks then why can't =
we
> simply ask if the data is a usable integer. At the end of the day it
> does depend on where the data was sourced? Binary data is only usable =
if
> we know that it is binary, or we will be converting some other format
> anyway?

I asked you for rules to recognize octal. I am all in favor of =
recognizing other numeric strings, hexa with leading 0x (detecting =
trailing h is more ambiguous and slower), for instance. It was removed =
some weeks ago for consistency reasons but it can be reintroduced in a =
consistent way in the future if needed.

> > 4. I'm assuming the stringy ints are rejected?
> Source material may be 'stringy ints', so all that does is say "we =
can't
> use the original variable it has to be converted" rather than we can =
and
> use it's 'non-stringy' view.

Can you explain? I don't understand.

> > 5. Is ".32" coerced to float or only "0.32"? Merely for =
clarification.
> Omitting the leading zero is normal when doing hand keyed data entry.
> .32 is a valid data entry ... Omitting perhaps 20% of characters =
speeds
> data entry.

No difference with PHP 5.

> > 6. Boolean coercion from other types... Not entirely sure myself.
> > Completely off the cuff: <=3D0: false, >0:true, floats and strings =
need
> > not apply.
> That would be a major BC break!

I am personally more in favor of reintroducing it. Test patch will show =
BC breaks and confirm.

> > 7. In string to float, only capital E or also small e?
> lower case e is common ...

Don't know. Check on php5. No change.

> > 8. I'll never stop call them "stringy" ints.
> For some funny reason we tend to prefer to view numbers on the screen =
as
> strings ... having the original string with a value which can be used
> for calculation is simply how I thought PHP worked. A variable is more
> than just a 'value', we need it's name which is a string, and a =
viewable
> string could be useful, along with other flags. I had assumed up until
> now that PHP was using that model but it seems not :(

It is *mostly* using that model. Unfortunately, history demands that =
$a[32] and $a["32"] behave in different ways. There are more cases but =
this one is the most common one.

Regards

Fran=C3=A7ois