Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116206
MIME-Version: 1.0
References: <CAB-BujZrArtUZa7taTKwSRg70eYsyM8hUO=iJj3bmo7mtw-XmA@mail.gmail.com>
 <CAFPFaMLYZ8a1369N9GbpG_tpmhBcmvUBiegdMF1QnR+wz0Gcdg@mail.gmail.com>
In-Reply-To: <CAFPFaMLYZ8a1369N9GbpG_tpmhBcmvUBiegdMF1QnR+wz0Gcdg@mail.gmail.com>
Date: Mon, 4 Oct 2021 10:35:04 +0200
Message-ID: <CAF+90c-9rbdZ7P25vFWhUx8AF6Hrt3Km=MgQ5GmdQs-hODXgtA@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: Andreas Hennings <andreas@dqxtech.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000014d77d05cd82cb63"
Subject: Re: [PHP-DEV] Unified ReflectionType methods
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000014d77d05cd82cb63
Content-Type: text/plain; charset="UTF-8"

On Sun, Oct 3, 2021 at 3:42 PM G. P. B. <george.banyard@gmail.com> wrote:

> On Sat, 2 Oct 2021 at 00:54, Andreas Hennings <andreas@dqxtech.net> wrote:
>
> > 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?
> >
> > -- Andreas
>
>
> I don't think this is a good idea, at least in a form like this.
> I understand that the ReflectionType API is cumbersome but I don't think
> merging everything together makes a lot of sense.
> Want does need to know if one is dealing with a Union, Intersection, or
> single type and conflating the APIs is IMHO a bad idea as it doesn't
> consider future extensions.
> And I am not talking about more complex composite types such as
> (A&B)|C|(X&Y), as those will be handled within the existing design, but
> potential additions to the type system like function types, literal types,
> generics, etc.
>
> I also don't really understand what the argument for removing instanceof
> checks is other than more generic code which works, but if this breaks at
> the next type system addition, this seems rather pointless.
>

Agree, I don't think this suggestion makes sense. The current
ReflectionType hierarchy is specifically designed so you have to do those
instanceof checks and deal with the different kinds of types we support.
The ReflectionType hierarchy isn't complex for fun, it directly reflects
the complexity of the type system. As the type system becomes more
complicated, there will be more kinds of types that are exposed through
reflection and need to be handled appropriately.

I am fine with additions as Tyson suggests them: Methods that work across
*all* ReflectionTypes. The proposed methods do not fall in this category,
as they don't hold up for intersection types in PHP 8.1 already, let alone
future type system additions.

Regards,
Nikita

--00000000000014d77d05cd82cb63--