Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83373
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>
In-Reply-To: <54E7A56E.2030005@birkholz.biz>
Date: Sat, 21 Feb 2015 03:03:47 +0100
Message-ID: <059801d04d7a$a0e9cc50$e2bd64f0$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIyuUwUVFIdYJq88tPJ7BNGL6d/pQFphJKyAV6NKKICWzu9jQGZbCefm/+QOxA=
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,

I didn't consider defining builtin type hints as classes because :

- I think it would be slower, and we need speed, but I agree, I did no =
test
- no pre-defined namespace exists to handle this
- 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.
- Storing builtin types in the root namespace would cause exactly the =
same problem of sharing a naming space with user-defined names.
- 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.

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.

Regards

Fran=C3=A7ois

> -----Message d'origine-----
> De : Dennis Birkholz [mailto:dennis@birkholz.biz]
> Envoy=C3=A9 : vendredi 20 f=C3=A9vrier 2015 22:22
> =C3=80 : internals@lists.php.net
> Objet : Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
>=20
> Hello
>=20
> Am 20.02.2015 um 22:03 schrieb Fran=C3=A7ois Laupretre:
> >> I just wonder why we need to prohibit these names. Can types not =
reside
> >> in the global \ namespace? We could then change the class =
resolution
> >> rules to allow to look also in \ as is done for functions =
currently.
> >>
> >> Thanks
> >> Dennis
> >
> > This is not a question of namespace resolution. Built-in type hints =
and
> namespaces have nothing in common.
>=20
> I do not know how the actual implementation works, but I assume there =
is
> a symbol table for each namespace that contains a list of
> class/trait/interface names for that namespace. Why not enhance this
> mechanism to contain all type information for each namespace? Simple
> types go into that symbol table, type aliases, type defs/enum types =
(if
> such a thing gets implemented), union types, etc. In addition, if the
> current namespace symbol table does not contain an entry (and the
> autoloader fails), the root namespace is tested for a name.
>=20
> > It is just about the logic of :
> >
> > Class resource {
> > ...
> > }
> >
> > Function foo(resource $arg, ...)
> >
> > Do we check $arg to be I_RESOURCE or an instance of the 'resource' =
class ?
>=20
> The class definition would give an error, as "resource" already exists
> in the topmost namespace.
>=20
> namespace test {
> 	Class resource { ... }
> 	function foo(resource $arg, ...)
> }
>=20
> function bar(resource $arg, ...)
>=20
> foo uses the class test\resource, bar uses the resource type from the
> root namespace.
>=20
> Maybe PHP works completely different internally and this is not
> feasible. But reserving some names from being valid as a class name
> sounds like a hack, I would prefer a clean and generic solution.
>=20
> Thanks
> Dennis
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php