Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83378
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: <54E8203A.7030001@birkholz.biz>
Date: Sat, 21 Feb 2015 07:05:46 +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> <54E7A56E.2030005@birkholz.biz> <059801d04d7a$a0e9cc50$e2bd64f0$@php.net>
In-Reply-To: <059801d04d7a$a0e9cc50$e2bd64f0$@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)

Hi François,

Am 21.02.2015 um 03:03 schrieb François Laupretre:
> I didn't consider defining builtin type hints as classes because :

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)".

> - I think it would be slower, and we need speed, but I agree, I did no test

I don't know this.

> - no pre-defined namespace exists to handle this

There is \

> - 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.

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.

> - Storing builtin types in the root namespace would cause exactly the same problem of sharing a naming space with user-defined names.

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.

> - 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.

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.

> 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.

Thanks
Dennis