Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116190
MIME-Version: 1.0
References: <CAB-BujZrArtUZa7taTKwSRg70eYsyM8hUO=iJj3bmo7mtw-XmA@mail.gmail.com>
 <DM5PR17MB14812ACD139468310B110EB3F9AC9@DM5PR17MB1481.namprd17.prod.outlook.com>
In-Reply-To: <DM5PR17MB14812ACD139468310B110EB3F9AC9@DM5PR17MB1481.namprd17.prod.outlook.com>
Date: Sun, 3 Oct 2021 08:18:47 +0200
Message-ID: <CAB-BujbwkH06zBGEav3rEQhhxxPsrAFTsSVZpmUG2ZvhZJg_2Q@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Unified ReflectionType methods
From: andreas@dqxtech.net (Andreas Hennings)

On Sat, 2 Oct 2021 at 16:37, tyson andre <tysonandre775@hotmail.com> wrote:
>
> Hi Andreas,
>
> > Hello list,
> > I would like to propose new methods for ReflectionType, that would
> > allow treating ReflectionNamedType and ReflectionUnionType in a
> > unified way.
> > This would eliminate the need for if (.. instanceof) in many use cases.
> >
> > Some details can still be discussed, e.g. whether 'null' should be
> > included in builtin type names, whether there should be a canonical
> > ordering of type names, whether we should use class names as array
> > keys, etc.
> > ...
> > What do you think?
>
> Relatedly, I also had different ideas lately about new methods for Reflec=
tionType, though of a different form.
>
> 1. To simplify code that would check `instanceof` for all current and fut=
ure types such as `never` and `mixed` and intersection types
>     `ReflectionType->allowsValue(mixed $value, bool $strict =3D true): bo=
ol`
>
>    Maybe also `allowsClass(string $className, bool $strict =3D true): boo=
l` to avoid needing to instantiate values (weak casting allows Stringable->=
string).

Ok for me, why not.
I would see it as a distinct PR, separate from my original proposal.
The problem or limitation of these methods is that they don't reflect
the full expressiveness of the type system.
That is, the return values of these methods would not be sufficient to
recreate an equivalent type.

> 2. To simplify code generation, e.g. in mocking libraries for unit testin=
g: `ReflectionType->toFullyQualifiedString(): string` (e.g. `\A|\B`) (may n=
eed to throw ReflectionType for types that can't be resolved, e.g. `parent`=
 in reflection of traits, keep `static` as is)
>
>     (The raw output of `__toString()` isn't prefixed with `\` (e.g. `A&B`=
) and can't be used in namespaces

Again, if we iron out the details, it can be a good idea as a distinct
standalone PR.

>
> The fact that both intersection and union types (and possibility of union=
 types of full intersection types)
> make it hard for me to believe that getBuiltinTypes and getBuiltinClasses=
 would be used correctly when used.

Just to mention it, my proposed names were getBuiltinNames() and
getClassNames() to be super clear that the return value will be
string[].

For future intersection types, there could be additional methods
getBuiltinIntersectionTypes() and getClassIntersectionTypes(), or it
would be a single method getIntersectionTypes(). Not sure yet which
combos make sense. E.g. array&callable would combine two builtin
types, Countable&callable would combine a class-like type and a
builtin type.
Every type would be broken into a normal form, where the top-level is
treated as a union type, and each item can either be a pure builtin
type, a pure class type, or an intersection of pure types.

int|string|(A&(B|(C&D))) =3D=3D=3D int | string | (A&B) | (A&C&D)

If we always use this normal form, then the ReflectionIntersectionType
only needs to have getBuiltinNames() and getClassNames(), not
getUnionTypes().

Not sure yet what to do with 'static' and '$this'.


>
> Thanks,
> Tyson
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>