PHP strict mode (strict types)

[dakujem]

Hello,

I recently started with Laravel again after 6 years and can't help but wonder why declare(strict_types=1); is not used throughout the framework and is not default in the artisan stubs...

I've been using and enforcing strict mode in all of my apps for years and happen to find this a downgrade.

Admittedly, I've been working with custom stacks, mostly, and I know Symfony is not using strict mode either. But I also know that Nette does.

I've been criticesed once for not using strict mode back when PHP 7 was fresh, I gradually started using it and never looked back. Now I'm dumbfounded that the prevalent frameworks have not caught up and started using strict mode in 8 years since introduction. Why?

[devajmeireles]

This is a control that the developer should have, not the framework. If Laravel sets out to solve all the thousands of problems that exist, it will grow to such an extent that the team will likely spin out of control.

When I started using Laravel I thought: "Why doesn't Laravel have helpers to solve math problems, equations, operations and other things?" Today I think: "Did I really think that? LOL" What kind of math problem can't we solve using normal expressions without resorting to tools?

[Sophist-UK]

Having thousands of add-on packages to choose from is a headache for sure. Before you decide to go with a package you need to be sure that it will be supported as Laravel goes from version to version, and that bugs you find will be fixed. And indeed, have some idea that the functionality will meet your needs. And IME sometimes these judgements can be very difficult making package selection a major headache.

But however bad this is, IMO having everything included in Laravel instead would be far, far worse.

[dakujem]

Guys, I'm not asking for oranges here.
Strict mode is not a feature, it's the way the framework is written and can not be controlled by users.

I'm asking why has the core team not adopted strict mode for internal use and encourage users (developers) to adopt it as well. That's all.

[dakujem]

Now that the summer vacations are over, is there anyone competent to answer my question or engage in discussion?

[henze-housepedia]

Since most of the framework isn't using type declarations but docblocks, it would be pretty useless. That, and I believe Taylor isn't a big fan of strong typing.... they say he said it in one of his Laravel Snippet podcast episodes, but I can't find that episode.

[dakujem]

Well that is interesting, because I find strong typing (with all the flexibility in PHP 8+) the best parts of modern PHP. Of course, there's places I do not use strong typing, deliberately, but one can always use mixed to indicate the type is generic on purpose.

[henzeb]

so do I. I think Jeffrey Way has explained it nicely why some are for and some are against it. And both sides have a point....

https://laracasts.com/podcast/df492049-000d-46cf-adea-d6903fb41c00

[dakujem]

Thank you. This has been very insightful. I'm obviously a proponent of types.

It is true that for simple usages there is no need for complex interfaces and stuff, that's what I do when I write application code, much of the time. This is a good point against types forcing types everywhere.

But when I write library code, good use of types and well-defined interfaces are the way for me. I'm quite defensive with code of my libraries, and there's less maintenance as a result.
In a framewrok, that is exactly what I would expect - to create boundaries, to hold the project together, to create a solid base. As a framework and library author myself, the realization the most prominent framework out there does not use typing is ... unsettling at best.

I love the flexibility in PHP, that both approaches can be used at the appropriate place. I just think that a framework is not the right place to use loose typing.

[Sophist-UK]

@henzeb I listened to (the beginning of) @JeffreyWay 's podcast where he explained the two sides' positions, but IMO this summary is incomplete and when you complete them IMO the case for Strict Typing is a much stronger one. In summary the two stated positions are:

1. Strict types - if method expects an INT then if I don't strict-type it, then I would need a few lines to validate that it is an INT and throw an exception if not. I also get IDE support.

2. Variable types - you don't need to write a few lines of validation code because I don't won't write calls which send non-INTs. And if I do, then the code will fail anyway and need fixing. And I can get IDE support using docblocks.

However point 2, is missing a few negatives though...

• Docblocks take significantly longer to write, and increase the number of lines of 'code'.

• Strict-types errors are immediately clear what the issue is. Not validating but instead waiting for some other random piece of code to fail will be far far harder to debug.

  The caller may have got the parameter passed to it and not be certain it is an INT. In this case, strict typing on the parameter passed to the caller would also help. Debugging a problem where someone passes a non-INT which is not type-checked for several layers of method/function calls until some random code fails is what I would describe as "debugging hell".

  These types of errors are also IME intermittent in nature - the code appears to work fine for maybe months, until some unvalidated data gets through and then it crashes. And IME intermittent errors are several orders of magnitude more difficult to debug than consistent errors - even if you work out that it was a type issue at the bottom of the stack, you may not know what the failing data was, or where it came from or what the user conditions were that created the issue. If it was a weird UI initiated problem you may never know what actions caused it and how to recreate it, fix it and test it.

  As a real example, a couple of days ago I had a crash in one of the open source(python) apps I use because I nudged the mouse or a key when I was doing something else at my desk and not looking at the screen - and the developer has no idea what the cause was or how to fix it. Having submitted some significant code enhancements in the past, I have a reasonable idea about the quality of their code, and I know that the code is not strictly typed (and indeed in some instances instead the developer has decided simply to ignores things when the type validation shows the wrong object type has been passed rather than even raise an exception), so when this caused a C++ exception inside a Python extension (inside a wx widget called by wxPython called by his app), neither of us had any idea what the data was, nor were either of us able to recreate the problem. Even more importantly, I doubt that the debugging will be any easier or more fruitful next time a user somehow initiates the same crash. I should add that I consider the overall software architecture of this app to be excellent, and the developer to be very talented - but he has one or two major blind-spots, strict-typing being one of them.

• IMO reliable code comes from code which is fully functionally and unit tested, and it is (for all practical purposes) impossible to write tests for every combination of non-typed parameter in every function/method. Strict-typing significantly reduces the number of possible alternatives you need to test. IMO this is a no-brainer reason to use strict-typing.

• I might agree with the variable typing enthusiasts if you had to chose a single type for parameters or results, however because you can union types, IMO you can get all of the benefits of strict-typing without losing the flexibility of variable typing.

(I have been in IT for several decades, and I have lost count of the number of times I have seen bugs which have resulted from type-issues - and when these (intermittent) errors have rarely occurred and I have had to debug them, it has almost always been a nightmare to track down what the cause is.)

[dakujem]

You have spoken right out of my mind somehow.

[Angel5a]

Let me put it this way: Would Laravel get stricter it become Nette.

Laravel is in a early stage of strict typing. I think it is because Laravel tries to have as low an input level and to be as friendly as possible. And loose type are better for beginners for sure. And it is useless and impossible to strict permissiveness. Personally, I count Laravel as RAD for web dev, but they going away from it in recent releases.

All the code is about duck-typing. All this method_exists instead of interfaces and base implementations. They are supposed to make it "easy to write" (which is wrong in terms of methods since you don't know what you have to write until you read the documentation or source code - IDE can't be helpful here, but knowing the docs is a good stuff), flexibility and freedom (you can return anything you want from the controller, and framework will take care about converting it to proper response).

All this stuff is great for prototyping and rapid development. PHP had loose type at start, but it got stricter in age. JavaScript had no strict types, but TypeScript appeared over time. As far as you need to do something quickly - loose type are great. As far as you work with a huge aged project - strict types are great. PHPUnit, Psalm, Phpstan, PHP_CodeSniffer and etc are good maturity indicators. They show, when you hit drawbacks of loose typing (like spending a day or week trying to track some nasty bag in other developers or your own code) and start to rigid your application.

And Laravel is not only about starterkit. It is good for matured projects as well. You just need to use good practices by yourself. Fell free to publish default templates and override them as you wish. Split your code, instead of placing all in the controller. Introduce you interfaces. Write sniffer snippets. Write portable code. Tests are out of box. These abilities are still up to you.

Sometimes, I lack strong typing in Laravel. But Laravel provides a good compromise. And, to be honest, most cases in web dev are quick development without supporting, and that way Laravel is winning on it's duck-typing.

P.S.: I feel more inconvenience from the lack of generics in PHP in general.

[simonrjones]

What's the current feeling in the Laravel Core team on introducing strict types into the Laravel codebase? I personally find it a more reliable way of developing with PHP.

The contribution docs don't discourage using types. I appreciate adding types across the entire codebase would be a big job, but this could be used progressively for new code. Since Laravel only supports PHP 8.2+ now and is clearly also used for larger web applications, it feels more realistic.

Another useful option (maybe an easier starting point) would be to add the ability for the make console command to generate code with declare(strict_types=1); - something I end up manually adding to code after it's been generated. This could potentially be controlled via a config option.

[henzeb]

I don't think the opinion has changed.

As for the code generation: you could use custom stubs. You need to publish them to your project for that.

[simonrjones]

Thanks for the suggestion but it's probably not worth adding custom stubs and they may get out of sync of the core Laravel code.