Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Optional typehint check for parameters »

[RFC] Optional typehint check for parameters

php.internals

Zeljko Mitic

8 years ago
PHP is dynamic language and each typed typehinted parameter has to be checked every time. I am suggesting new php.ini value "typecheck.enable = 1" which can be turned off. Example: with default php config, a code like this would check each member of $users array: function demo(User ...$users) {} but with "typecheck.enable = 0", same code would be treated like it was written this way: function demo(...$users) {} Basically, php would simply *ignore* typehints and work like they are not there. It would be programmers responsibility to send correct values but people using typehints are not those still learning the basics. Just like it is programmers responsibility to restart php-fpm when using opcache.validate=0, it would be theirs responsibility to send correct values. Any decent IDE would mark errors for wrong parameter type and with tools like phpstan, it is almost impossible to make one. Only development computers would need to have this checks turned on. This creates no BC problems as it is a new feature. Given that typechecks can be turned off, all existing programs would benefit from extra speed. I am sending this mail by following rules from https://wiki.php.net/rfc/howto . I don't have any knowledge of php internals so unfortunatelly, I can't help with this. I at least hope someone will take this RFC into consideration.

Arvids Godjuks

8 years ago
On Sun, Jul 15, 2018, 22:45 Zeljko Mitic <mitke013@gmail.com> wrote:
> PHP is dynamic language and each typed typehinted parameter has to be > checked every time. I am suggesting new php.ini value "typecheck.enable = > 1" which can be turned off. > > Example: > with default php config, a code like this would check each member of $users > array: > > function demo(User ...$users) {} > > but with "typecheck.enable = 0", same code would be treated like it was > written this way: > > function demo(...$users) {} > > Basically, php would simply *ignore* typehints and work like they are not > there. > > It would be programmers responsibility to send correct values but people > using typehints are not those still learning the basics. > > Just like it is programmers responsibility to restart php-fpm when using > opcache.validate=0, it would be theirs responsibility to send correct > values. Any decent IDE would mark errors for wrong parameter type and with > tools like phpstan, it is almost impossible to make one. Only development > computers would need to have this checks turned on. > > This creates no BC problems as it is a new feature. Given that typechecks > can be turned off, all existing programs would benefit from extra speed. > > I am sending this mail by following rules from > https://wiki.php.net/rfc/howto . I don't have any knowledge of php > internals so unfortunatelly, I can't help with this. I at least hope > someone will take this RFC into consideration. >
Hello, php.ini settings that modify language behaviour on such large scale are not up for introduction or even discussion. PHP has been getting rid of those past 10 years, so forgive me for harshness, but as a user land developer I say "no chance In hell". Arvids,

Zeljko Mitic

8 years ago
I tried to, but I honestly can't see the problem. No decent programmer makes error by sending wrong type of parameter and this feature is 100% optional. I know for sure that even in my dev computer, I would use this feature, and probably most programmers aware of the issue. Maybe simpler example: if I send a string to above function, the only difference is that PHP would start executing inner code. But an inner line like $user->getEmail() would still throw fatal error, still very easy to spot. But again, I really don't see that happening and I am not an expert. And I still never make errors like that, not even when I was learning php. And if dev computer keeps checking type (default), it is very easy to spot a big mistake like that. Given this is open discussion, I would like to see where I was wrong. Btw, you were not harsh at all. On Mon, Jul 16, 2018 at 8:01 AM Arvids Godjuks <arvids.godjuks@gmail.com> wrote:

Zeljko Mitic

8 years ago
On Mon, Jul 16, 2018 at 12:56 PM Zeljko Mitic <mitke013@gmail.com> wrote:
> I tried to, but I honestly can't see the problem. No decent programmer > makes error by sending wrong type of parameter and this feature is 100% > optional. I know for sure that even in my dev computer, I would use this > feature, and probably most programmers aware of the issue. > > Maybe simpler example: if I send a string to above function, the only > difference is that PHP would start executing inner code. But an inner line > like $user->getEmail() would still throw fatal error, still very easy to > spot. > > But again, I really don't see that happening and I am not an expert. And I > still never make errors like that, not even when I was learning php. And if > dev computer keeps checking type (default), it is very easy to spot a big > mistake like that. > > Given this is open discussion, I would like to see where I was wrong. > > Btw, you were not harsh at all. > > > On Mon, Jul 16, 2018 at 8:01 AM Arvids Godjuks <arvids.godjuks@gmail.com> > wrote: > >> On Sun, Jul 15, 2018, 22:45 Zeljko Mitic <mitke013@gmail.com> wrote: >> >>> PHP is dynamic language and each typed typehinted parameter has to be >>> checked every time. I am suggesting new php.ini value "typecheck.enable = >>> 1" which can be turned off. >>> >>> Example: >>> with default php config, a code like this would check each member of >>> $users >>> array: >>> >>> function demo(User ...$users) {} >>> >>> but with "typecheck.enable = 0", same code would be treated like it was >>> written this way: >>> >>> function demo(...$users) {} >>> >>> Basically, php would simply *ignore* typehints and work like they are not >>> there. >>> >>> It would be programmers responsibility to send correct values but people >>> using typehints are not those still learning the basics. >>> >>> Just like it is programmers responsibility to restart php-fpm when using >>> opcache.validate=0, it would be theirs responsibility to send correct >>> values. Any decent IDE would mark errors for wrong parameter type and >>> with >>> tools like phpstan, it is almost impossible to make one. Only development >>> computers would need to have this checks turned on. >>> >>> This creates no BC problems as it is a new feature. Given that typechecks >>> can be turned off, all existing programs would benefit from extra speed. >>> >>> I am sending this mail by following rules from >>> https://wiki.php.net/rfc/howto . I don't have any knowledge of php >>> internals so unfortunatelly, I can't help with this. I at least hope >>> someone will take this RFC into consideration. >>> >> >> Hello, >> >> php.ini settings that modify language behaviour on such large scale are >> not up for introduction or even discussion. >> PHP has been getting rid of those past 10 years, so forgive me for >> harshness, but as a user land developer I say "no chance In hell". >> >> Arvids, >> >
I am sorry for last message; I know I should have put my response at bottom, but I missclicked in gmail. I wrote the message, remembered the rules and instead of revealing quoted text, I clicked on "send".

Arvids Godjuks

8 years ago
пн, 16 июл. 2018 г. в 13:56, Zeljko Mitic <mitke013@gmail.com>:
> I tried to, but I honestly can't see the problem. No decent programmer > makes error by sending wrong type of parameter and this feature is 100% > optional. I know for sure that even in my dev computer, I would use this > feature, and probably most programmers aware of the issue. > > Maybe simpler example: if I send a string to above function, the only > difference is that PHP would start executing inner code. But an inner line > like $user->getEmail() would still throw fatal error, still very easy to > spot. > > But again, I really don't see that happening and I am not an expert. And I > still never make errors like that, not even when I was learning php. And if > dev computer keeps checking type (default), it is very easy to spot a big > mistake like that. > > Given this is open discussion, I would like to see where I was wrong. > > Btw, you were not harsh at all. >
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. Long story short in a time of php 5.3 - 5.6 it was collectively agreed that switches that control language execution are evil, are hard to maintain and having language behave differently due to hosting enforcing one or the other setting and you as a user having no way to control that is just bad. Since then, the most evil switches were purged with extreme pregidece and trying to introduce anything even remotly close to that is a suicide mission :) P.S. RIP magic_quotes, register_globals, short_tags and some other articats of old. May you never be disturbed again.
-- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius

Zeljko Mitic

8 years ago
On Mon, Jul 16, 2018 at 1:06 PM Arvids Godjuks <arvids.godjuks@gmail.com> wrote:
> пн, 16 июл. 2018 г. в 13:56, Zeljko Mitic <mitke013@gmail.com>: > >> I tried to, but I honestly can't see the problem. No decent programmer >> makes error by sending wrong type of parameter and this feature is 100% >> optional. I know for sure that even in my dev computer, I would use this >> feature, and probably most programmers aware of the issue. >> >> Maybe simpler example: if I send a string to above function, the only >> difference is that PHP would start executing inner code. But an inner line >> like $user->getEmail() would still throw fatal error, still very easy to >> spot. >> >> But again, I really don't see that happening and I am not an expert. And >> I still never make errors like that, not even when I was learning php. And >> if dev computer keeps checking type (default), it is very easy to spot a >> big mistake like that. >> >> Given this is open discussion, I would like to see where I was wrong. >> >> Btw, you were not harsh at all. >> > > 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. > > Long story short in a time of php 5.3 - 5.6 it was collectively agreed > that switches that control language execution are evil, are hard to > maintain and having language behave differently due to hosting enforcing > one or the other setting and you as a user having no way to control that is > just bad. Since then, the most evil switches were purged with extreme > pregidece and trying to introduce anything even remotly close to that is a > suicide mission :) > > P.S. RIP magic_quotes, register_globals, short_tags and some other > articats of old. May you never be disturbed again. > > > -- > Arvīds Godjuks > > +371 26 851 664 > arvids.godjuks@gmail.com > Skype: psihius > Telegram: @psihius https://t.me/psihius >
Ok, I see your point now. Bit isn't opcache.validate exactly the opposite of that? When user deploys the code, he would not see changes before fpm is restarted. Or worse; if opcache didn't cache some file because it was not called before, more problems would happen. But please, do keep in mind that I would like to have this feature as optional.

Arvids Godjuks

8 years ago
пн, 16 июл. 2018 г. в 14:14, Zeljko Mitic <mitke013@gmail.com>:
> > > On Mon, Jul 16, 2018 at 1:06 PM Arvids Godjuks <arvids.godjuks@gmail.com> > wrote: > >> пн, 16 июл. 2018 г. в 13:56, Zeljko Mitic <mitke013@gmail.com>: >> >>> I tried to, but I honestly can't see the problem. No decent programmer >>> makes error by sending wrong type of parameter and this feature is 100% >>> optional. I know for sure that even in my dev computer, I would use this >>> feature, and probably most programmers aware of the issue. >>> >>> Maybe simpler example: if I send a string to above function, the only >>> difference is that PHP would start executing inner code. But an inner line >>> like $user->getEmail() would still throw fatal error, still very easy to >>> spot. >>> >>> But again, I really don't see that happening and I am not an expert. And >>> I still never make errors like that, not even when I was learning php. And >>> if dev computer keeps checking type (default), it is very easy to spot a >>> big mistake like that. >>> >>> Given this is open discussion, I would like to see where I was wrong. >>> >>> Btw, you were not harsh at all. >>> >> >> 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. >> >> Long story short in a time of php 5.3 - 5.6 it was collectively agreed >> that switches that control language execution are evil, are hard to >> maintain and having language behave differently due to hosting enforcing >> one or the other setting and you as a user having no way to control that is >> just bad. Since then, the most evil switches were purged with extreme >> pregidece and trying to introduce anything even remotly close to that is a >> suicide mission :) >> >> P.S. RIP magic_quotes, register_globals, short_tags and some other >> articats of old. May you never be disturbed again. >> >> >> -- >> Arvīds Godjuks >> >> +371 26 851 664 >> arvids.godjuks@gmail.com >> Skype: psihius >> Telegram: @psihius https://t.me/psihius >> > > Ok, I see your point now. Bit isn't opcache.validate exactly the opposite > of that? When user deploys the code, he would not see changes before fpm is > restarted. Or worse; if opcache didn't cache some file because it was not > called before, more problems would happen. > > But please, do keep in mind that I would like to have this feature as > optional. >
Opcache is not the PHP language - it's an opcode caching tool that is bundled with PHP engine for performance reasons. It does not change language construct behavior. It does not impact the application behavior - it only affects code loading performance. Think of it as a memcache/redis for your database - same idea.
-- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius

Lester Caine

8 years ago
On 16/07/18 12:14, Zeljko Mitic wrote:
> But please, do keep in mind that I would like to have this feature as > optional.
The problem with most of these 'improvements' to PHP is that the case is always made that 'you do not have to use it' and this is yet another load on the code base that 'you do not have to use'. However SOMEONE will come up with a use in a library that means one has little option but to have to use it and switching off would break that. As Yasuo has said, there are other ways of doing the same thing, and moving the 'problem' over to the IDE allows a LOT more flexibility in doing this sort of code management. The fact that once added, typehint is then a done deal, other areas will also be under pressure to enforce typing and we are stuck with one sides restricted view of how it should work. EVERY variable has a range of limitations and simply enforcing a 'number' when it also needs to be tested for size STILL needs the docblock comments to provide THAT information. Since most processing starts with text strings, enforcing binary data rules already needs some means of converting the input to binary and so is it really so bad to pass the raw variable and test that it is in the correct range within the function ... and PROPERLY handle an invalid input within the proper program flow rather than kicking it out to some other part of the code. Adding a valid default replacing the duff entry may be the correct response. Having to handle all of that BEFORE calling the function is simply the wrong way of programming! Switches to control what features are enablled may no longer be politically correct, but not providing options for some of these 'extras' is just going to increase the pressure on not upgrading and nothing I am seeing for PHP7.3 gives me any reason to need to worry about using it at all ... typehints are certainly an extra negative to changing ... 7.0.x is stable on my LTS platform, so I'll stay on that ...
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Rowan Collins

8 years ago
On 16 July 2018 at 12:06, Arvids Godjuks <arvids.godjuks@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]

Zeljko Mitic

8 years ago
On Mon, Jul 16, 2018 at 1:42 PM Rowan Collins <rowan.collins@gmail.com> wrote:
> On 16 July 2018 at 12:06, Arvids Godjuks <arvids.godjuks@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.

Larry Garfield

8 years ago
On Monday, July 16, 2018 12:23:42 PM CDT Zeljko Mitic wrote:
> On Mon, Jul 16, 2018 at 1:42 PM Rowan Collins <rowan.collins@gmail.com> > > wrote: > > On 16 July 2018 at 12:06, Arvids Godjuks <arvids.godjuks@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.
That fails with the potential for dynamic typing. $class = derive_class_name($_GET['some_input']); $foo = new $class(); doStuff($foo); function doStuff(BarInterface $b) { ... } In PHP you *cannot* know with certainty that all code is type safe at compile time. Removing type checks at runtime will *always* lead to reduced safety and at best less useful error messages. That's just the nature of the language. PHP is not Rust (as cool as that would be). It sounds like your main argument for why to even bother with this is performance. I think you're greatly over-estimating the performance impact of type checking. I wager if you just cache a few database lookups and you'll get a much larger performance win. For far, far less effort and confusion. --Larry Garfield

Rowan Collins

8 years ago
On 16 July 2018 at 19:17, Larry Garfield <larry@garfieldtech.com> wrote:
> It sounds like your main argument for why to even bother with this is > performance. I think you're greatly over-estimating the performance > impact of > type checking. I wager if you just cache a few database lookups and > you'll > get a much larger performance win. For far, far less effort and confusion. >
That's true of *current* type hints, but performance has absolutely been cited as a reason not to introduce additional features, such as typed arrays (e.g. int[] $foo or array<int,int> $foo). I think that's the motivation here, rather than optimizing existing code. Regards,
-- Rowan Collins [IMSoP]

Nikita Popov

8 years ago
On Sun, Jul 15, 2018 at 9:39 PM, Zeljko Mitic <mitke013@gmail.com> wrote:
> PHP is dynamic language and each typed typehinted parameter has to be > checked every time. I am suggesting new php.ini value "typecheck.enable = > 1" which can be turned off. > > Example: > with default php config, a code like this would check each member of $users > array: > > function demo(User ...$users) {} > > but with "typecheck.enable = 0", same code would be treated like it was > written this way: > > function demo(...$users) {} > > Basically, php would simply *ignore* typehints and work like they are not > there. > > It would be programmers responsibility to send correct values but people > using typehints are not those still learning the basics. > > Just like it is programmers responsibility to restart php-fpm when using > opcache.validate=0, it would be theirs responsibility to send correct > values. Any decent IDE would mark errors for wrong parameter type and with > tools like phpstan, it is almost impossible to make one. Only development > computers would need to have this checks turned on. > > This creates no BC problems as it is a new feature. Given that typechecks > can be turned off, all existing programs would benefit from extra speed. > > I am sending this mail by following rules from > https://wiki.php.net/rfc/howto . I don't have any knowledge of php > internals so unfortunatelly, I can't help with this. I at least hope > someone will take this RFC into consideration. >
Independently of the question of whether we want to do this at all or not, there is a technical difficulty here: While most type checks are just that, scalar type checks (in particular in coercive mode) may perform type conversions. You pass "42" to a parameter accepting int and the parameter will become 42. Just disabling type checks completely would mean that the function now receives "42", which actively violates the type contract (even though the code was completely error free with enabled type checks). How do you propose to handle these cases? Nikita

Zeljko Mitic

8 years ago
On Mon, Jul 16, 2018 at 1:14 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Sun, Jul 15, 2018 at 9:39 PM, Zeljko Mitic <mitke013@gmail.com> wrote: > >> PHP is dynamic language and each typed typehinted parameter has to be >> checked every time. I am suggesting new php.ini value "typecheck.enable = >> 1" which can be turned off. >> >> Example: >> with default php config, a code like this would check each member of >> $users >> array: >> >> function demo(User ...$users) {} >> >> but with "typecheck.enable = 0", same code would be treated like it was >> written this way: >> >> function demo(...$users) {} >> >> Basically, php would simply *ignore* typehints and work like they are not >> there. >> >> It would be programmers responsibility to send correct values but people >> using typehints are not those still learning the basics. >> >> Just like it is programmers responsibility to restart php-fpm when using >> opcache.validate=0, it would be theirs responsibility to send correct >> values. Any decent IDE would mark errors for wrong parameter type and with >> tools like phpstan, it is almost impossible to make one. Only development >> computers would need to have this checks turned on. >> >> This creates no BC problems as it is a new feature. Given that typechecks >> can be turned off, all existing programs would benefit from extra speed. >> >> I am sending this mail by following rules from >> https://wiki.php.net/rfc/howto . I don't have any knowledge of php >> internals so unfortunatelly, I can't help with this. I at least hope >> someone will take this RFC into consideration. >> > > Independently of the question of whether we want to do this at all or not, > there is a technical difficulty here: While most type checks are just that, > scalar type checks (in particular in coercive mode) may perform type > conversions. You pass "42" to a parameter accepting int and the parameter > will become 42. > > Just disabling type checks completely would mean that the function now > receives "42", which actively violates the type contract (even though the > code was completely error free with enabled type checks). > > How do you propose to handle these cases? > > Nikita >
That is good question, I didn't think of that. I think better solution would be to only typecheck objects, conversion still happens. I didn't want to mention the story behind it. I would really like php to have generics, or at least typed arrays. I recently read that someone tried to implement typed array and got 15% slow-down; I am sorry I can't provide link, reddit is just to big place :) So if speed is major problem of advancing towards generics/typed arrays, I think this optional feature would solve it. Programmer would still spot problem on dev computers where speed is not relevant. I hope I explained this correctly, english is not my first language.

Zeljko Mitic

8 years ago
On Mon, Jul 16, 2018 at 1:44 PM Zeljko Mitic <mitke013@gmail.com> wrote:
> > > On Mon, Jul 16, 2018 at 1:14 PM Nikita Popov <nikita.ppv@gmail.com> wrote: > >> On Sun, Jul 15, 2018 at 9:39 PM, Zeljko Mitic <mitke013@gmail.com> wrote: >> >>> PHP is dynamic language and each typed typehinted parameter has to be >>> checked every time. I am suggesting new php.ini value "typecheck.enable = >>> 1" which can be turned off. >>> >>> Example: >>> with default php config, a code like this would check each member of >>> $users >>> array: >>> >>> function demo(User ...$users) {} >>> >>> but with "typecheck.enable = 0", same code would be treated like it was >>> written this way: >>> >>> function demo(...$users) {} >>> >>> Basically, php would simply *ignore* typehints and work like they are not >>> there. >>> >>> It would be programmers responsibility to send correct values but people >>> using typehints are not those still learning the basics. >>> >>> Just like it is programmers responsibility to restart php-fpm when using >>> opcache.validate=0, it would be theirs responsibility to send correct >>> values. Any decent IDE would mark errors for wrong parameter type and >>> with >>> tools like phpstan, it is almost impossible to make one. Only development >>> computers would need to have this checks turned on. >>> >>> This creates no BC problems as it is a new feature. Given that typechecks >>> can be turned off, all existing programs would benefit from extra speed. >>> >>> I am sending this mail by following rules from >>> https://wiki.php.net/rfc/howto . I don't have any knowledge of php >>> internals so unfortunatelly, I can't help with this. I at least hope >>> someone will take this RFC into consideration. >>> >> >> Independently of the question of whether we want to do this at all or >> not, there is a technical difficulty here: While most type checks are just >> that, scalar type checks (in particular in coercive mode) may perform type >> conversions. You pass "42" to a parameter accepting int and the parameter >> will become 42. >> >> Just disabling type checks completely would mean that the function now >> receives "42", which actively violates the type contract (even though the >> code was completely error free with enabled type checks). >> >> How do you propose to handle these cases? >> >> Nikita >> > > That is good question, I didn't think of that. I think better solution > would be to only typecheck objects, conversion still happens. > > I didn't want to mention the story behind it. I would really like php to > have generics, or at least typed arrays. I recently read that someone tried > to implement typed array and got 15% slow-down; I am sorry I can't provide > link, reddit is just to big place :) > > So if speed is major problem of advancing towards generics/typed arrays, I > think this optional feature would solve it. Programmer would still spot > problem on dev computers where speed is not relevant. > > I hope I explained this correctly, english is not my first language. >
I am really sorry for messing up my previous message. First, I clicked "reply" instead of "reply all". When I saw that, I used copy&paste and my last message appeared as quote. I hope you can read it, this will (hopefully) not happen again.

Yasuo Ohgaki

8 years ago
On Mon, Jul 16, 2018 at 4:46 AM Zeljko Mitic <mitke013@gmail.com> wrote:
> PHP is dynamic language and each typed typehinted parameter has to be > checked every time. I am suggesting new php.ini value "typecheck.enable = > 1" which can be turned off. > > Example: > with default php config, a code like this would check each member of $users > array: > > function demo(User ...$users) {} > > but with "typecheck.enable = 0", same code would be treated like it was > written this way: > > function demo(...$users) {} > > Basically, php would simply *ignore* typehints and work like they are not > there. >
What you need is DbC. It's more flexible and complete. It satisfies all of your needs and more. An issue is that DbC is not static code analysis tool friendly. https://wiki.php.net/rfc/introduce_design_by_contract https://wiki.php.net/rfc/dbc https://wiki.php.net/rfc/dbc2 Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Christoph Becker

8 years ago
On 16.07.2018 at 13:15, Yasuo Ohgaki wrote:
> What you need is DbC. > It's more flexible and complete. It satisfies all of your needs and more. > An issue is that DbC is not static code analysis tool friendly. > > https://wiki.php.net/rfc/introduce_design_by_contract > https://wiki.php.net/rfc/dbc > https://wiki.php.net/rfc/dbc2
All three RFCs are marked as being “Under Discussion”, which doesn't appear to be the case.
-- Christoph M. Becker

Dan Ackroyd

8 years ago
On 15 July 2018 at 20:39, Zeljko Mitic <mitke013@gmail.com> wrote:
> PHP is dynamic language and each typed typehinted parameter has to be > checked every time.
If you think your code would benefit appreciably from having parameter types removed, I would strongly recommend looking at https://preprocess.io/ and similar libraries. Preprocessing is used in Javascript to quite radically change what is possible to code in 'Javascript' and has allowed rapid development in how 'Javascript' can be used. For example JSX is something that would never have been approved by the ECMA committee.....but because it was implemented a preprocessing step it never needed to be approved before could get wide-scale usage. cheers Dan Ack

Zeljko Mitic

8 years ago
On Tue, Jul 17, 2018 at 1:18 PM Dan Ackroyd <danack@basereality.com> wrote:
> On 15 July 2018 at 20:39, Zeljko Mitic <mitke013@gmail.com> wrote: > > PHP is dynamic language and each typed typehinted parameter has to be > > checked every time. > > If you think your code would benefit appreciably from having parameter > types removed, I would strongly recommend looking at > https://preprocess.io/ and similar libraries. > > Preprocessing is used in Javascript to quite radically change what is > possible to code in 'Javascript' and has allowed rapid development in > how 'Javascript' can be used. For example JSX is something that would > never have been approved by the ECMA committee.....but because it was > implemented a preprocessing step it never needed to be approved before > could get wide-scale usage. > > cheers > Dan > Ack >
It won't help, preprocess.io doesn't remove typehints. But this is mostly intended for other features like generics/typed arrays for which I have read that speed is a big blocker. Anyway, if anyone is interested, I did some testing on parameter check. The code: --- class Customer {} function test(Customer $customer) {} $customer = new Customer(); $start = microtime(true); for ($i=1;$i<100000000;$i++) { // 100 million test($customer); } echo microtime(true) - $start; --- Tested 3 times, average time: 3.58s When I removed typehint from test() function, average time was: 2.76s Difference is 29.7% I know it is unrealistic scenario because there is nothing else in the code, I was just curios.

Dan Ackroyd

8 years ago
On 17 July 2018 at 13:08, Zeljko Mitic <mitke013@gmail.com> wrote:
> > It won't help, preprocess.io doesn't remove typehints.
It doesn't _currently_ remove parameter types. If you think this is an idea worth doing, you could write the functionality to do that. cheers Dan

Zeljko Mitic

8 years ago
On Tue, Jul 17, 2018 at 3:39 PM Dan Ackroyd <danack@basereality.com> wrote:
> On 17 July 2018 at 13:08, Zeljko Mitic <mitke013@gmail.com> wrote: > > > > It won't help, preprocess.io doesn't remove typehints. > > It doesn't _currently_ remove parameter types. > > If you think this is an idea worth doing, you could write the > functionality to do that. > > cheers > Dan >
To be honest, I did think of that after I replied. But then I saw one big problem; autowiring containers like Symfony (which I use) will not work anymore. So this is definitely a no-go.