Property type hints in Codeigniter 4 (or just PHP 7.4 as a requirement) |
Hey there all, I hope your days are going well.
So, I was combing through the code to help clean up some of the documentation and refactor some of the classes while getting ready to issue a pull request. I have a quick question regarding this, and will await a response before issuing the PR. Is there any reason why we would not want to use property types in the framework and application classes? For example, the performance increases are extremely beneficial as well as the desired effects. With strongly typed properties, users of the framework will have to adhere to these types. I was looking in system/Config/BaseConfig.php. Let's use this base example. Say we were to use typed properties, like below: Instead of: Code: /** We can use this, to make the intentions of the framework's base configuration more clear and throw an error when improperly used. Code: /** Perhaps a side effect could be that there would be fewer questions on the forums since PHP will do what it does and tell end users where they went wrong in their application? Either way that is a vague example but a proof of concept none-the-less. Now I realize that this requires PHP 7.4 and the minimum requirement is 7.2 (last I checked). However, I can make the argument that if CodeIgniter is going to utilize PHP 7's capabilities, it should keep up with them. Typed properties being an example. Null coalesce assignment being another or limited return type covariance and argument type contravariance. These features have helped assist in bringing PHP 7.4 into the fastest state the language has been yet. And it also allows for a slightly more opinionated expected use of the framework itself by making clearer some of the intentions of the frameworks developers. I guess the real question is, can we utilize PHP 7.4 in CodeIgniter going forward? Or are we to stick with the requirement of PHP >= 7.2? Either way, to keep up with the times and technology, we should at least try to utilize some of the features where they can be best taken advantage of. I hope this makes sense, it has been a long day and I am typing this while extremely tired. Thanks for listening to my rambling
“A reader lives a thousand lives before he dies. The man who never reads lives only one.”
George R.R. Martin
Check out my GitHub repositories
At this time there are no intentions to raise minimum requirements to 7.4. Those on shared hosting have a limited selection of 7.2 capable-hosting as it is, the last time I checked. No need to make that even more difficult.
There is also no desire to move the framework to a completely strict typed system. Unless you've seen benchmarks that I haven't the performance gains from doing so are minimal compared to things like accessing the database, which would be one of my first choices for somewhere to optimize. PHP, as a language, is loosely typed and currently the framework takes advantage of that fact. If you want a strictly typed version there is another user on the forums that maintains a modified version, I believe.
(01-17-2020, 08:09 PM)kilishan Wrote: At this time there are no intentions to raise minimum requirements to 7.4. Those on shared hosting have a limited selection of 7.2 capable-hosting as it is, the last time I checked. No need to make that even more difficult. Thank you Lonnie. This all makes sense of course, I just wanted to check. Just to be clear my intention was more along the lines of using PHP 7.4's features as a reason to advance the minimum requirement, strict types was more of an example of that. Null coalesce assignment is one example. So is Support for weak references, covariant returns and contravarian parameters is another, or the ability to unpack arrays inside of arrays to eliminate array_merge() calls is another. More of a testament to the language itself and its maturity, and whether CodeIgniter had plans to take advantage of these benefits where it made sense since PHP 7.4 has resulted in some pretty great performance benchmarks as seen here. Especially since PHP now has preloading and speed is always something CodeIgniter showcases. Fortunately, CodeIgniter is the one framework that has always catered to the majority of users on shared hosting, etc. So that fact triumphs over other technological features I would imagine. Anyways, thanks for entertaining my tired brains ideas
“A reader lives a thousand lives before he dies. The man who never reads lives only one.”
George R.R. Martin
Check out my GitHub repositories
There is nothing to stop you from using PHP 7.4 on your projects and taking advantage of the performance benefits and other features in your own code.
Well of course I could . I was talking about at the framework level. Taking advantage of key features of the language as it matures should be at least of interest to the core development team I would imagine because the framework would mature with the language. Although I do understand that CodeIgniter would like to cater to the majority and that has always been one of its strongest attributes.
Thanks again Lonnie, I just thought I would see what the opinion was on something like this .
“A reader lives a thousand lives before he dies. The man who never reads lives only one.”
George R.R. Martin
Check out my GitHub repositories
(01-17-2020, 08:09 PM)kilishan Wrote: At this time there are no intentions to raise minimum requirements to 7.4. Those on shared hosting have a limited selection of 7.2 capable-hosting as it is, the last time I checked. No need to make that even more difficult. I really don't want to insult anybody but this is a perfect example why people think that CodeIgniter is not on par with other frameworks. It feels like the developers are somewhat divided into different groups. One that wants progress, on that wants backwards compatibility.
No offense taken. The most popular PHP framework around currently is Laravel. It has a minimum requirement of 7.2 also. Symphony has 7.2.5. Cake is minimum 7.2. It's not just us.
Not everyone is in control of their server. Some people like to build products they can sell to people at which point having shared hosting requirements that are a challenge pose a blocker to people buying their products. Composer is not a requirement for the "download and go" packages. We use it to keep a couple of third-party packages up to date. If you want to use Composer then it works out of the box. I have never come across a hosting configuration that cannot be setup to work with /public formats. CPanel is the challenging environment but even there it's possible. December 2020 is a year away. We have time to evaluate and make the change. As for type hints and Entities, in my experience things have a tendency to come out of the database as a string, which is what makes casting and mutations helpful. The fun I have with this argument is that when I decided to make 7.2 the minimum a while back I got a fair amount of flack for that. No winning I guess.
My shared hosting uses public_html and all I have to do is change the public folder to public_html
and everything works just fine. Lucky for me my shared hosting will put any version of php that I want on my site. What did you Try? What did you Get? What did you Expect?
Joined CodeIgniter Community 2009. ( Skype: insitfx )
(01-21-2020, 07:39 AM)kilishan Wrote: No offense taken. The most popular PHP framework around currently is Laravel. It has a minimum requirement of 7.2 also. Symphony has 7.2.5. Cake is minimum 7.2. It's not just us. I would say that you're correct in that you can't win . Unfortunately (or fortunately?) the PHP language has always been ridiculed and ostracized due to its loose types and this is why we see a concious effort to move the PHP core to a stronger typed language. I understand the arguments being made for catering to the demographics of a larger audience, and I respect it. However, as a framework it'll be very hard to be taken seriously again after all the years of crap that it has received, by and large. One way to remedy this or even remove the uncertainty, would be to prove to the PHP world that the core dev team at CodeIgniter is ready to take it forward, only forward and not worry too much about BC breaks. Which brings me to this: if the EOL for PHP is a "year away", are we going to expect the core team to issue a press-release come November or early December and surprise its users with a "guess what, PHP 7.2 reaches EOL now. Time to upgrade because going forward we are in the frameworks core requiring a minimum of PHP >=7.x", and catching everyone off guard? Or, would it possibly be beneficial to just say, before the release of 4.0, to say "Hey, we require a minimum of PHP 7.4 from the git go". Therefor nullifying anyones expectations of less. I'm only asking because I can see it now. Imagine the PHP world being hit with the release of arguabley the oldest lasting (one of) PHP framework requiring PHP 7.4 as a minimum. One that nearly all the way up until now has been mostly ridiculed for being "old and out dated" or "not exploiting the newest technologies". There would be no way it couldn't be taken seriously. Perhaps it would bring more people to the framework from other frameworks like Slim and Laravel due to the implied seriousness and assertions of where it wants to go. This is touching only on the PR aspect of it, not even mentioning the actual benefits of the languages newest iterations. I may be rambling again and I apologize if I am. I'm typing this from my phone at work so it's a bit of a doozy haha. Either way keep it up Lonnie and know that regardless, some of us trust your judgement with the framework moving forward and will use it and contribute to it none-the-less
“A reader lives a thousand lives before he dies. The man who never reads lives only one.”
George R.R. Martin
Check out my GitHub repositories
Honestly - it's too soon to know. I'm just trying to get a 4.x release out and sort out everything now that I've taken on Jim's mantle as well. Future plans are not made, but I would expect we'd give plenty early warning before making a change like that.
|
Welcome Guest, Not a member yet? Register Sign In |