Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83100
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.4 as permitted sender)
Reply-To: <francois@php.net>
To: "'Rowan Collins'" <rowan.collins@gmail.com>,
	<internals@lists.php.net>
References: <CAESVnVoZYiMWQk1Ydc-9wbkJo7Ru_4mrUtrubW=Rh=QKK9o8TA@mail.gmail.com> <CAPwsocFUF9WcTxc-BjmaCccdPbeYs5VgyDvqYbx=3cR-SwoPkg@mail.gmail.com> <032f01d04b92$2722e0d0$7568a270$@php.net> <54E4BEDA.70009@gmail.com>
In-Reply-To: <54E4BEDA.70009@gmail.com>
Date: Wed, 18 Feb 2015 19:05:07 +0100
Message-ID: <036201d04ba5$6e09d6d0$4a1d8470$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQKz6wpj8b81mnwJq1LfxWbU4ZJyQgFU2plEApzjh9IB/ophVJr/7j5A
Content-Language: fr
Subject: RE: [PHP-DEV] Scalar Type Hints v0.4
From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=)

> De : Rowan Collins [mailto:rowan.collins@gmail.com]
>
> What if we defined the types as names in the \PHP namespace, but =
defined
> a slightly different algorithm for resolving typehints vs other uses:
>=20
> function foo(\PHP\types\numeric $a) // unambiguous but unwieldy
> function foo(\My\Namespace\numeric $a) // unambiguously *not* a =
built-in
> type
> function foo(numeric $a) // ambiguous, resolved at compile time
>=20
> The name would be resolved as follows:
>=20
> Given a typehint $type:
> 1) If $type begins with '\PHP\types\', interpret it it as an internal =
type.
> 2) ElseIf $type contains '\', interpret it as a class name, and =
proceed
> with normal class resolution at runtime.
> 3) ElseIf \PHP\types\$type is the name of a built-in type, interpret =
it
> as that internal type.
> 4) Else, interpret it as a class name, and proceed with normal class
> resolution at runtime.
>=20
> Basically, this means you can do the following:
>=20
> class String {}
> function accept_scalar_string(string $string) { ... }
> function accept_string_object(\String $string) { ... }
>=20
>=20
> The nice thing about this is that if we ever allow users to define
> "basic" types - copy-on-write structs, range types, enums, etc - they
> could "extend" these built-in types.
>=20
> Does that make sense to anyone, or am I over-complicating things?

Well, that's a solution, at least theoretically speaking.

Frankly, I find it unreadable and I don't see reserving \PHP\types as a =
clean solution. IMO, adding semi-virtual namespaces would be mostly =
confusing and would just hide the initial name clash issue.

There are a lot of other ways to extend type hinting to user-defined =
types. Maybe we will reserve namespaces for this case. In your design, =
where would these user types go ? in \PHP\usertype\ ? or would they =
share \PHP\types with built-in types (which recreates the same issue) ?

Regards

Fran=C3=A7ois



>=20
> Regards,
> --
> Rowan Collins
> [IMSoP]
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php