Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101318
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain dqxtech.net from 209.85.215.41 cause and error)
MIME-Version: 1.0
In-Reply-To: <CADyq6sLW=EkM-k0b7z5WEz-h=GxHozK69dgoOWG=S5o2WTy=Bg@mail.gmail.com>
References: <CAH0Uv3EUxGMp2d+kt8jGEpiLSxBzN=JwJViwRAiiyouVgPi6Eg@mail.gmail.com>
 <CADyq6sLW=EkM-k0b7z5WEz-h=GxHozK69dgoOWG=S5o2WTy=Bg@mail.gmail.com>
Date: Mon, 11 Dec 2017 10:21:08 +0100
Message-ID: <CAH0Uv3Gtnf8x==DMfLD9TuPfXi3gGzmReNnQpb-Ee4K_jGa+LQ@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Reflection API: Add static factories on ReflectionType
From: andreas@dqxtech.net (Andreas Hennings)

On 11 December 2017 at 08:58, Marco Pivetta <ocramius@gmail.com> wrote:
> What's the use-case for creating a userland `ReflectionType` instance,
> besides mocking the reflection API itself?
> Consider that the subclassing in userland already provides an easy way to
> perform these operations (although ugly):
> https://github.com/Roave/BetterReflection/blob/2.0.1/src/Reflection/Adapter/ReflectionType.php

You are right.
And it does not even need BetterReflection library, it only needs one
single class which can also be defined locally.
It only needs $this->name, $this->allowsNull and $this->isBuiltin as
private properties.

(nothing against the library, just in case someone only needs this one feature)



Still, I think having a documented native constructor and/or static
factories would make this API more complete.
Without this, it seems like someone walked away from a construction site.

Also, inheriting from core reflection classes, I imagine always
carries some baggage.
(as opposed to implementing an interface)



>
> Not trying to drag down your proposal, but as you can see this is already
> being done and works very well and is very well tested for BC compliance
> (should new methods land into `ReflectionType`).
>
> Also, I'd add that a the proposed API should accept
> `InternalType|ReflectionClass|null`, and not `string` (separate named
> constructors would be best) which is basically the reason for most
> hair-pulling around the PHP lang.
>
> A small `InternalType` VO that throws on `InternalType::fromString() : self`
> would be extremely beneficial to avoid the continuously growing list of edge
> cases and additions required to accommodate for new internal types being
> added to the language.
>
> On 11 Dec 2017 08:25, "Andreas Hennings" <andreas@dqxtech.net> wrote:
>
> Currently there is no (documented) way to directly create a
> \ReflectionType object.
> The class has no documented constructor.
>
> I propose that static factory methods shall be added for this purpose.
>
> This will be useful for code that wants to dynamically create and pass
> around reflection type objects.
>
>
> /** @var bool $allowsNull */
>
> $t1 = \ReflectionType::fromBuiltinType('string', $allowsNull);
> $t2 = \ReflectionType::fromClassName(\stdClass::class, $allowsNull);
>
> assert(true === $t1->isBuiltin());
> assert(false === $t2->isBuiltin());
>
> assert('string' === $t1->getName());
> assert(\stdClass::class === $t2->getName());
>
>
> To be discussed:
> - method names
> - Whether to return ReflectionNamedType or ReflectionType or something else.
>
> (I don't find ReflectionNamedType documented in
> http://php.net/manual-lookup.php?pattern=ReflectionNamedType)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>