On Mon, Jul 16, 2018 at 1:42 PM Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 16 July 2018 at 12:06, Arvids Godjuks <arvids.godj...@gmail.com> wrote: > >> Basically, you went wrong when you proposed a switch that controlls >> language behavior. To add to that - a switch that probably is not >> controllable by code that is running. >> > > > While I agree with your general principle here, I would like to raise one > point in this proposal's favour, which is that PHP's type hints are > effectively assertions - if the value is not of the given type at that > point, an error is raised. Assertions are always something you turn off in > production builds, with a global switch, to the point of compiling the code > as though they don't exist, so it's not unreasonable to have a similar > switch to disable run-time type checks. > > As Nikita points out, this is not true of non-strict scalar hints, so that > does raise a complication. > > I was going to point to Dart as an example where type checks have been > implemented this way, but it seems that version 2 has replaced the "checked > mode" with stronger static analysis, and run-time checks are automatically > inserted only for cases where the safety can't be inferred. > > This might actually be a more promising optimisation for PHP - perhaps > OpCache could mark certain code paths as type-safe (or maybe it already > does?) As an exaggerated example, this code only really needs to check the > value's type once, not four times: > > function foo(Bar $bar): Bar { > return $bar; > } > function test(Bar $bar): Bar { > return foo($bar); > } > $something = test($something); > > Regards, > -- > Rowan Collins > [IMSoP] > Exactly. Languages like Java and Hack will not compile when sent parameter is of wrong type. Once all is OK, generated code will never check that value again. My suggestion is something between; if during development my code works, I don't ever need type check again. it doesn't have to be php.ini configuration. Maybe even better solution would be to have different PHP installation. Example, instead of "apt install php7.2", user would do "apt install php7.2-nocheck". So if opcode-equivalent of php7.2.exe looks like this: --- assert_type(User, TypeError) some opcode 1 some opcode 2 --- in that other php7.2-nocheck.exe, opcode would look: --- some opcode 1 some opcode 2 --- Or if it is simpler, assert_type would be blank opcode. It is similar to how Symfony works; using compiler passes, programmer can replace slow service with faster one, as long as it is same interface. For example logger service; in production, I don't need most of stuff written to log file as I need in development mode. So instead of constantly checking which environment my code is running in, I always use $logger->info('something'). But in production, expensive logger service is replaced with one that has no code in that method. Hopefully I explained it correctly, although this logger example is fictional.