Better types without runtime checking

On Tue, Jun 5, 2018 at 4:23 PM Rudolph Gottesheim r.gottesheim@loot.at
wrote:

There's always a lot of talk about types in the PHP community.
Specifically, many developers want property types, generics, function
signature types, union and intersection types, and more. Those talks
(and RFCs) always end with the same result: "We can't do it because
performance issues."

Has there ever been a discussion about adding some of those features
syntactically, but ignoring them during runtime? At least until someone
finds a performant way to check them at runtime. That way we could have
advanced type checking in our editors at least.

The idea will sound familiar to TypeScript users. It works great for
that language.

I'm excited to hear your opinions.

DbC style has no performance issue at all. In addition, you can perform
much better validation than simple type checks.

function f($username) {
assert(is_string($username) && preg_match('\A[a-z]\z', $username);
....
}

--
Yasuo Ohgaki
yohgaki@ohgaki.net

On Tue, Jun 5, 2018 at 2:22 AM Rudolph Gottesheim r.gottesheim@loot.at
wrote:

There's always a lot of talk about types in the PHP community.
Specifically, many developers want property types, generics, function
signature types, union and intersection types, and more. Those talks
(and RFCs) always end with the same result: "We can't do it because
performance issues."

Has there ever been a discussion about adding some of those features
syntactically, but ignoring them during runtime? At least until someone
finds a performant way to check them at runtime. That way we could have
advanced type checking in our editors at least.

The idea will sound familiar to TypeScript users. It works great for
that language.

It's an interesting compromise, but I worry about the confusion it may sow,
particularly for incoming programmers from languages that do enforce such
things - such as Java.

Has there ever been a discussion about adding some of those features
syntactically, but ignoring them during runtime? At least until someone
finds a performant way to check them at runtime. That way we could have
advanced type checking in our editors at least.

You can have that today: https://preprocess.io/

The main thing that would missing would be a mapping of source file +
line to the running code, which would make debugging harder.

cheers
Dan

There's always a lot of talk about types in the PHP community.
Specifically, many developers want property types, generics, function
signature types, union and intersection types, and more. Those talks
(and RFCs) always end with the same result: "We can't do it because
performance issues."

Has there ever been a discussion about adding some of those features
syntactically, but ignoring them during runtime? At least until
someone finds a performant way to check them at runtime. That way we
could have advanced type checking in our editors at least.

Hi,

I believe this is part of the original aim of Hack-Lang: the additional
type features of that language are not part of the run-time, but checked
by a static analysis tool offline. A number of languages have similar
setups - Python and Dart both have the types as offline and/or
development-mode-only features. Indeed, PHP seems to have gone a very
unusual route in having a dynamic language with type constraints which
are effectively always-on assertions.

One of the problems with moving PHP to this offline-checking model is
that people will expect new type constraints to work like existing ones,
so may be caught out by them not being checked at run-time. Worse,
static checks may not be able to detect certain violations; I don't know
much about Hack's model, but I understand it includes both different
levels of strictness, and restrictions on dynamic language features -
things like references, "variable variables", and non-object callables.

I do think it's an interesting question to think about though.

Regards,

--
Rowan Collins
[IMSoP]

...
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.