[RFC] Optional typehint check for parameters

пн, 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

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

On Mon, Jul 16, 2018 at 1:42 PM Rowan Collins rowan.collins@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.