Better types without runtime checking

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

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); .... }

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

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.

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

On 05/06/2018 08:22, Rudolph Gottesheim wrote:

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,

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

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.