Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83380
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: "'Dennis Birkholz'" <dennis@birkholz.biz>,
	<internals@lists.php.net>
References: <CAESVnVoJW3EQu254kztSG_1QjJjnqLJkxHOEL+gofwpJC7D40A@mail.gmail.com> <54E7822F.4070307@fischer.name> <54E7882B.30800@birkholz.biz> <057201d04d50$be289f00$3a79dd00$@php.net> <54E7A56E.2030005@birkholz.biz> <059801d04d7a$a0e9cc50$e2bd64f0$@php.net> <54E8203A.7030001@birkholz.biz>
In-Reply-To: <54E8203A.7030001@birkholz.biz>
Date: Sat, 21 Feb 2015 07:53:45 +0100
Message-ID: <05bf01d04da3$23575b80$6a061280$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIyuUwUVFIdYJq88tPJ7BNGL6d/pQFphJKyAV6NKKICWzu9jQGZbCefApuByDcBVPucIpvgZlaA
Content-Language: fr
Subject: RE: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

Hi Dennis,

Please give more precise examples. I'm afraid I don't understand :

If you use \ as prefix for builtin types, how do you distinguish this =
from classes ? Would \resource mean the builtin type or a class name ?

Do you mean no class could be defined under \ ?

Syntax for union types ?

Regards

> -----Message d'origine-----
> De : Dennis Birkholz [mailto:dennis@birkholz.biz]
> Envoy=C3=A9 : samedi 21 f=C3=A9vrier 2015 07:06
> =C3=80 : internals@lists.php.net
> Objet : Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
>=20
> Hi Fran=C3=A7ois,
>=20
> Am 21.02.2015 um 03:03 schrieb Fran=C3=A7ois Laupretre:
> > I didn't consider defining builtin type hints as classes because :
>=20
> I was not proposing using internal types as classes. I just want to
> define a clean behavior for all kinds of types that may exist some =
time
> in PHP. As no scalar type hints RFC has passed so far, we could also
> define it in a clean way and just put the scalar types into \, then we
> can not have the conflicting classes there and have to use "function
> foo(\int $c)" instead of "function foo(int $c)" which is a lot better
> that switching type hints for classes to something like "function bar
> (object(my\namespaced\class) $a)".
>=20
> > - I think it would be slower, and we need speed, but I agree, I did =
no test
>=20
> I don't know this.
>=20
> > - no pre-defined namespace exists to handle this
>=20
> There is \
>=20
> > - Reverting to the root namespace makes it twice slower. The case of
> functions is nothing more than a hack to have a flawed design approved =
by all
> means.
>=20
> Also you could just "use \int, \string;" on top of the file, than
> "function foo(int $c)" is ok. In total, I think that is the BC-break
> safe way to go, it will keep the door wide open for union types, etc.
> without the worry of BC breaks. We could leave out all the hacky stuff
> here. We could even use \PHP as the namespace to go.
>=20
> > - Storing builtin types in the root namespace would cause exactly =
the same
> problem of sharing a naming space with user-defined names.
>=20
> No, because you can just move you classes into a namespace and add =
some
> use statements to the top of the consumer files (with different
> namespaces in use). With the current proposals, you have to invent new
> names for you classes.
>=20
> > - and probably the most important one: the implementation is based =
upon
> the ZPP layer, which allows internal and userland type hinting to =
follow
> exactly the same logic.
>=20
> I consider this a detail that should not prevent a clean language
> design. It may mean more work in the short time but I think this will
> greatly increase the adoption rate if we can eliminate the BC break =
here.
>=20
> > About namespaces : no type hinting feature is currently planned at =
the
> namespace level, except the usual class resolution when a class name =
is used
> as hint. Some may exist in the future as there will probably be more =
links
> between built-in types and classes, such as specializing and combining =
builtin
> types using a userland class or exposing builtin-types as classes.
>=20
> Thanks
> Dennis
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php