Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115602
MIME-Version: 1.0
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <CAOWwgpne5MEBxdvz=Q_zmRf=1abtQstMfpLXW4gbfp4+dRokfA@mail.gmail.com>
In-Reply-To: <CAOWwgpne5MEBxdvz=Q_zmRf=1abtQstMfpLXW4gbfp4+dRokfA@mail.gmail.com>
Date: Wed, 28 Jul 2021 13:38:37 +0100
Message-ID: <CA+kxMuQHz5U7D2E8gRyxxAfToJM6zc721qxLFcZFuTuiarVy3w@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: [RFC] Nullable intersection types
From: Danack@basereality.com (Dan Ackroyd)

On Wed, 28 Jul 2021 at 08:29, Nicolas Grekas <nicolas.grekas@gmail.com> wrote:
> Nullability is a special beast in PHP. We have a range of operators
> dedicated to it. That's also why I think it deserves special care, and why
> I think it's important to have this discussion before 8.1 is out.

Why does this change need to be done now, rather than wait for 8.2?

I can't see a clear reason in the RFC and saying 'nullability is
special' doesn't seem a clear reason either. If you think you'll only
be able to use intersection types when they can be union'ed with null,
then ... just wait until they are?

Andreas Leathley wrote:
> Having one clear RFC voting option (with no
> secondary syntax voting option) also seems the most honest, as if
> somebody agrees that nullability would be useful but would only accept
> one syntax choice, that seems impossible to represent, necessitating a
> no vote on the whole RFC.

I strongly agree with this.

Having a situation where people will want to change their primary
vote, based on which option in a secondary vote is winning is a "not
good" situation.

Having syntax for a type system be chosen by a popularity contest,
where many of the voters are not aware of the implications of the
choices is also not good.

RFC authors should be trying to pass an RFC they are sure is the right
choice, not leaving important decisions up in the air.

Larry Garfield wrote:
> Some other mechanism such as the sometimes discussed type
> aliases provides an alternate way to solve this problem.

This is an important point and why trying to push changes to the type
system through after feature freeze is a bad idea.

The example in the RFC uses single letter class names; in my
experience most classes have quite a few more letters in them than
that. Trying to use intersection types with realistic class names
leads to code like this, for a custom cache definition*.

function foo(Get|GetOrDefault|Set|SetWithTTL|GetOrGenerate|Clear $cache) {
   ...
}

Which is pretty unreadable. I don't think I'll be using intersection
types much until PHP has the capability to compose types. e.g.
something similar to this:

type SimpleCache = Get|GetOrDefault|Set|SetWithTTL|GetOrGenerate|Clear;

function foo(SimpleCache $cache) {
   ...
}

At which point the need for being able to include nullability in the
intersection type goes away. You can instead use the existing ability
to indicate a type can be null:

function foo(?SimpleCache $cache) {
   ...
}

So yeah....I agree that widespread adoption of intersection types
might not happen in 8.1 but that's fine, and better than possibly
implementing the wrong thing after feature freeze.

Nicolas Grekas wrote:
> polishing features that are about to be released.

Changes to the type system are not polish.

cheers
Dan
Ack


* Custom cache definitions.

The conversation that the PHP FIG had around caching was very
contentious. Everyone involved has their own idea of what features
absolutely had to be in the interface, and what stuff should be left
out.

Some people just needed 'get' and 'set', some people needed a
moderately complex cache, and other people needed an 'enterprise'
level cache system that has full thundering herd protection.

Trying to come up with a single implementation that makes everyone
happy was an inherently impossible task.

Instead of that, defining individual interfaces for each of the
methods, and then allowing people to implement/use as many as they
want to, allows for interoperability without having a One True Cache
to rule them all, and so avoids having a prize to be fought over. So
something like:

interface Get {
    public function get(string $key): mixed;
}

interface GetOrDefault {
    public function getOrDefault(string $key, mixed $default): mixed;
}

interface Set {
    public function set(string $key, mixed $value): void;
}

interface SetWithTTL {
    public function set(string $key, mixed $value): void;
}

interface GetOrGenerate {
    // Gets a key if it exists, or calls $fn to generate the value
    // and stores the value, before returning it.
    public function get(string $key, callable $fn): mixed;
}

interface Clear {
    public function clear(string $key): void;
}