Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83357
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain birkholz.biz does not designate 144.76.185.252 as permitted sender)
Message-ID: <54E7A56E.2030005@birkholz.biz>
Date: Fri, 20 Feb 2015 22:21:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAESVnVoJW3EQu254kztSG_1QjJjnqLJkxHOEL+gofwpJC7D40A@mail.gmail.com> <54E7822F.4070307@fischer.name> <54E7882B.30800@birkholz.biz> <057201d04d50$be289f00$3a79dd00$@php.net>
In-Reply-To: <057201d04d50$be289f00$3a79dd00$@php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Reserve EVEN MORE types for PHP7
From: dennis@birkholz.biz (Dennis Birkholz)

Hello

Am 20.02.2015 um 22:03 schrieb François 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.

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.

> 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 ?

The class definition would give an error, as "resource" already exists
in the topmost namespace.

namespace test {
	Class resource { ... }
	function foo(resource $arg, ...)
}

function bar(resource $arg, ...)

foo uses the class test\resource, bar uses the resource type from the
root namespace.

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.

Thanks
Dennis