Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102228
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.192.178 cause and error)
MIME-Version: 1.0
In-Reply-To: <0d108361-f5fa-fe76-b6ad-66e23bfa88f5@loot.at>
References: <0d108361-f5fa-fe76-b6ad-66e23bfa88f5@loot.at>
Date: Mon, 11 Jun 2018 16:12:21 +0200
Message-ID: <CADqTB_iFe4RD1dswEtBvD8ho15hgvrGBC+wBnBzv+yXokkuApQ@mail.gmail.com>
To: Rudolph Gottesheim <r.gottesheim@loot.at>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Better types without runtime checking
From: rasmus@mindplay.dk (Rasmus Schultz)

On Tue, Jun 5, 2018 at 9:22 AM, Rudolph Gottesheim <r.gottesheim@loot.at> wrote:
> ...
> Has there ever been a discussion about adding some of those features
> syntactically, but ignoring them during runtime?

That's what Hack does, and one of the main reasons we dropped Hack in
favor of PHP.

PHP is a reflective language - if we add e.g. generics or property
type-hints, omitting run-time reflection and/or run-time type-checks
would be inconsistent with PHP as a language in general.

Inconsistencies in a language are surprising and generally "bad" - if
type-hints lead to run-time type-checks, it's natural to expect that
to work predictably no matter where you type-hint. You shouldn't have
to learn where or when type-hints actually work at run-time and where
they don't.

Similarly, if type-hints are reflected, it's natural to expect all
type-hints to exist in the reflection model somewhere, anywhere that
type-hinting is possible. You shouldn't have to search the manual to
learn that type-hints aren't reflected for properties for some reason,
perhaps because it just hasn't been implemented yet.

Much of the "good" that we expect to be able to accomplish with
generics, for example, won't be possible (or won't make sense) without
being consistently reflected and  run-time type-checked.

For example, in a DI container, I'd expect to be able to do something like this:

    class Container {
        public function get<T>(?string $name): T {
            // ...
        }

        // ...
    }

When calling get(), I'd expect a type-check for the the generic
return-type T, to protect me against internal errors in the Container
implementation - if it returns the wrong type, I want it to fail
immediately at that point, rather than potentially exiting the
call-stack that made this error traceable, making this extremely
difficult to debug.

Similarly, if we had property type-hints:

    class Foo {
       int $bar;
    }

    $foo = new Foo();

    $foo->bar = "oops";

Here, I'd expect a type-check when assigning to $bar - omitting that
would be extremely bad, as, very likely, by the time something else
fails because this object is in an invalid state, we've exited the
call stack where the bad value was assigned, making this potentially
very difficult to debug.

I'd also expect to be able to reflect on the property-types in a DI
container, or perhaps in a class that maps form post-data to
properties and performs conversions, etc.

I'm the author of the generics RFC and one of the property-type RFCs,
and both of those RFCs call for both reflection and run-time
type-checking, for the sake of keeping the language consistent.

Hack made some very regrettable decisions in this area, and ultimately
those features were useful at design-time only, for IDE-support - but
we have php-doc for that purpose, and in my opinion, adding those
features before (or unless) we're willing/able to also make them work
consistently with the language, does more harm than good. Making these
features appear to be language features, when in fact that they're
only implemented in the parser and ignored by the interpreter, would
make for an extremely confusing experience.