Closed holtkamp closed 7 years ago
v2.0.0 will be 7.x only, but I currently don't have any plans for setting up strict typing. I'll gladly leave this open in case anyone else wants to make a case for it though.
There hasn't been any movement on this, so closing. Thanks for the recommendation though.
I'll gladly leave this open in case anyone else wants to make a case for it though.
You mean as in "+1s" or offers to come up with a PR?
Maybe an idea to set up a separate branch where such work on v2.0.0 can be collected?
Once you have experienced the sweetness of strict typing and return types, you never want to go back 😄
I'd like to see a real-world reason we should switch to strict typing. Just because the feature exists doesn't mean we have to use it.
There's been barely, if any, issues reported because of improper parameter data being passed, or users being confused by the public API. Most issues, especially the ones now hopefully fixed in master
, were due to faulting business logic when it came to validating data. That's not something solved by strict typing.
I've used strict typing, and in some cases it can be useful. For most code I don't see an overarching need for it, especially in a library that tends to use mostly \DateTime
and values that can be of multiple types.
So, at the moment, I don't see a need for strict typing in this library. If anyone would like to convince me otherwise, I'm willing to listen. This issue has sat here for more than half a year though with no movement for or against strict typing, which is why I closed it.
Ok, thanks for taking the time to explain your stance in such detail.
In my experience it particularly helps to decrease chances of minor bugs during development.
Does the restriction to only support PHP
7.0+
pave the way to increase strictness?Thinking of:
declare(strict_types=1)
This would probably require a new major release, since run-time type casting would not be allowed anymore...