Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83002
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: "'Sara Golemon'" <pollita@php.net>,
	"'Rasmus Lerdorf'" <rasmus@lerdorf.com>
Cc: "'Philip Sturgeon'" <pjsturgeon@gmail.com>,
	"'Arvids Godjuks'" <arvids.godjuks@gmail.com>,
	"'Jefferson Gonzalez'" <jgmdev@gmail.com>,
	"'Rowan Collins'" <rowan.collins@gmail.com>,
	"'PHP internals'" <internals@lists.php.net>
References: <011801d04a07$83ab1c00$8b015400$@php.net>	<CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>	<016f01d04a3a$e9183220$bb489660$@php.net>	<CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>	<54E290E5.3020508@lerdorf.com>	<CAESVnVpXmmfDh6iqT=n27iHQ21_QxPWkez_=bEc1Dpn+MNrjMg@mail.gmail.com>	<54E2AD88.6040206@lerdorf.com>	<CAESVnVoFD7-A2_a1ZPR9av2tiVbbs7D0NUt0TihH-dQFvhkH6Q@mail.gmail.com>	<54E2FA57.6050009@lerdorf.com> <CAESVnVqjGJS8rJaYyrEkX-Y6KCaM=e+z9xEYyH9A7NkgYO0YAw@mail.gmail.com>
In-Reply-To: <CAESVnVqjGJS8rJaYyrEkX-Y6KCaM=e+z9xEYyH9A7NkgYO0YAw@mail.gmail.com>
Date: Tue, 17 Feb 2015 20:13:46 +0100
Message-ID: <027701d04ae5$dadb3670$9091a350$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGD0sLDaA+/0NIeBlQhQC5OtPA/xwHih9+6AanvcsEBj7eMCwMCOrTfAf9SX8UA7o1xMwLzIgWkAYs8fFwBy0roOJ0DcvCg
Content-Language: fr
Subject: RE: [PHP-DEV] Reviving scalar type hints
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : php@golemon.com [mailto:php@golemon.com] De la part de Sara
> Golemon
>
> > 1. Tighten up the type coercion for the "1000 dogs" case although we
> >    have to look at whether there is a problem with some database =
APIs
> >    returning space-padded fields so "1000    " would now break.
> >    Hopefully that is fringe enough to not break the world.
> >
> Hopefully, though I think that we could embrace the idea of trailing
> space as insignificant.

I'll propose *leading* and *trailing* whitespaces :) This doesn't cost =
much and can prove useful.

> > 2b. A much more flexible system for specifying multiple types. I =
should
> >     be able to say that my function takes something that looks like =
a
> >     number if I choose and still take advantage of stricter typing =
for
> >     other parameters.
> >
> Union types.  I'm hear a lot of support for this concept, and not
> exclusively from one camp.
> Perhaps with a psuedo-type defined somewhere to account for the
> half-type "numeric string".

'numeric' can be implemented in two ways : a union type, or a new zpp =
type. I think I prefer the flexibility of union types. Maybe we'll have =
to include it in the first release, finally :)

> > 3. Don't turn on crazy-strict mode for internal functions that =
weren't
> >    designed for that. Instead provide the same ability as userspace =
gets
> >    for developers to gradually design their APIs to be stricter if =
they
> >    so desire allowing both Hack and PHP to implement a stricter
> >    curl_setopt(), for example.
> >
> Perhaps a ZEND_ACC_STRICT flag which lets an API opt-in to strict =
mode?
> Or something passed to the arg_info struct? The details are secondary,
> but you get my meaning...

I prefer defining four new 'strict' ZPP types for int, float, bool, and =
string (others are already strict). This way, the function decides what =
it accepts, not the user. Anyway, if we implement union types as =
strict-only, we will need these types.

Regards

Fran=C3=A7ois