CodeIgniter Forums

Full Version: CI 4.0.3 is releasing soon - help wanted
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hey all - I'm shooting for a May 1 release date for 4.0.3. I could really use your help jumping in and helping to fix out/investigate any of the issues over at GitHub so we can get stomp as many bugs as possible before that release. If you're not comfortable jumping in to help on the code side, polishes to the user guide are always helpful, too!

Thanks a lot!
This is great news! I hope that most of the problems from the "Issues" branch will be fixed!
I extend my thanks to everyone who supported the development process.
Hi there.

I totally agree that the codeigniter user manual must be make more user friendly for first time users.
(04-22-2020, 04:33 AM)shewolf255 Wrote: [ -> ]I totally agree that the codeigniter user manual must be make more user friendly for first time users.

If you could be so kind to provide constructive criticism on what type of error you found in the user guide, we could correct the error. The user guide aren't a complete tutorial but a book you can look up what function are available, and see short usage examples. So you need to fill in the blanks yourself, and by blanks I mean using different type of libraries together to make a complete application.

You are more than welcome to make updates to the user guide, as it's hard for us to guess what you have troubles with. What parts need more in depth descriptions.
(04-20-2020, 09:56 PM)kilishan Wrote: [ -> ]Hey all - I'm shooting for a May 1 release date for 4.0.3. I could really use your help jumping in and helping to fix out/investigate any of the issues over at GitHub so we can get stomp as many bugs as possible before that release. If you're not comfortable jumping in to help on the code side, polishes to the user guide are always helpful, too!

Thanks a lot!

Errors will show and stop the page from rendering by adding declare(strict_types=1); to all PHP files.

I only found about half a dozen easily fixed bugs when I added strict types.

Give it a whirl and I think you will be pleasantly surprised Smile
John - we've had this discussion before. Smile
(04-22-2020, 10:57 AM)kilishan Wrote: [ -> ]John - we've had this discussion before. Smile
Yes I know and I was outvoted by Luddites not willing to use the available debugging tools. I think their reasoning is because they prefer coding with blinkers/blinders and afraid the additional errors will mean more work in tracing bugs.

Take a look at all the bugs that had to be fixed with a particular Github download in the following link. There were only three bugs found and that included using the Mysqli table from Playground. 

https://ci4-strict.tk/bugs-fixed

Please ignore the index.php modifications which override the conflicting CI_DEBUG conflicting variable types.
(04-22-2020, 04:08 PM)John_Betong Wrote: [ -> ]
(04-22-2020, 10:57 AM)kilishan Wrote: [ -> ]John - we've had this discussion before. Smile
Yes I know and I was outvoted by Luddites not willing to use the available debugging tools. I think their reasoning is because they prefer coding with blinkers/blinders and afraid the additional errors will mean more work in tracing bugs.

That was me the discussion happened with, so calling me a Luddite isn't the best way to move your case forward. Those are only bugs when you turn on a feature that restricts another feature (automatic type casting). To say they're bugs when the framework isn't designed with strict typing in mind is a fallacy.

It boils down to personal preferences. I understand the benefits and drawbacks of strict and loose typing, and, for this case, choose loose typing. I respect that you prefer the strict typing. And that's cool. Too bad you can't respect our choices.

And, as always - anyone is able to submit a PR to fix things they don't like.
(04-22-2020, 10:04 PM)kilishan Wrote: [ -> ]
(04-22-2020, 04:08 PM)John_Betong Wrote: [ -> ]
(04-22-2020, 10:57 AM)kilishan Wrote: [ -> ]John - we've had this discussion before. Smile
Yes I know and I was outvoted by Luddites not willing to use the available debugging tools. I think their reasoning is because they prefer coding with blinkers/blinders and afraid the additional errors will mean more work in tracing bugs.

That was me the discussion happened with, so calling me a Luddite isn't the best way to move your case forward. Those are only bugs when you turn on a feature that restricts another feature (automatic type casting). To say they're bugs when the framework isn't designed with strict typing in mind is a fallacy.

It boils down to personal preferences. I understand the benefits and drawbacks of strict and loose typing, and, for this case, choose loose typing. I respect that you prefer the strict typing. And that's cool. Too bad you can't respect our choices.

And, as always - anyone is able to submit a PR to fix things they don't like.


Please accept my sincere apologies for the Luddite reference it was not specifically aimed at yourself and I do respect your choice to not use strict typing. I have vague memories about other users who condemned strict type usage without even trying to see the benefits.

What I find confusing with the existing application is declaring numerous function parameter types and not using the strict_type declaration? I would have thought they were included and ready to be used at a later date?

Regarding strict_type drawbacks I have never read a valid argument against their usage. PHP introduced them a couple of years ago and they are still used, same for numerous other compiled languages. As previously mentioned I really like how errors are thrown when parameter types do not match. While developing the errors are easily eliminated.

I am very busy at the moment and once I clear the backlog will endeavour to update the online usage and to submit PRs.

Keep up the good work Smile
Pages: 1 2