-
Notifications
You must be signed in to change notification settings - Fork 1.9k
fix: ValidationInterface #6253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: ValidationInterface #6253
Conversation
fa82cb5
to
f89bd78
Compare
f89bd78
to
0710013
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this much better. Let's still see what happens on the main thread but this is a good example of modifying the interface. I expect this to have way lower impact than changing Model constructor signature.
0710013
to
d7cfb6a
Compare
Rebased. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good by me! Offering a final chance to #develop
@iRedds have you seen this? |
@MGatner In fact, I think that interface hell is going on in the framework. In particular, this applies to the HTTP layer. When instead of describing the public API in interfaces, methods are moved to traits. Instead of inheritance, interfaces are enumerated in a class. But for some reason these methods are missing.
|
@@ -198,7 +197,7 @@ abstract class BaseModel | |||
/** | |||
* Our validator instance. | |||
* | |||
* @var Validation | |||
* @var ValidationInterface | |||
*/ | |||
protected $validation; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me that it makes sense to specify the property type directly instead of docBlock in BaseModel and Controller.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The existing user's Model will break.
https://3v4l.org/NkQVr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why override the property?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. I don't know, but we can override.
I should have said, the existing user's Model might break.
Oh very much so! Please see #5909 if you haven't already. Basically after much discussion: we've decided to update the interfaces with the missing methods that are already used internally. This is a big "no no" but so is the current state, and this has the least likely path to ruin people's existing code.
I'm on mobile so can't really search the framework right now. @kenjis have you determined these aren't necessary for the interface? |
I didn't determined, but at least these methods are not needed in the current framework implementation. If we change this return type |
Each Service should return an Interface or Abstract Class (when relevant). Remember that Services is our "alternative to a Container. So yes: we should add these methods if they are needed for our service locator to support the interface. |
Maybe it's easier to announce the development of the 5th version and already start writing correctly? |
It's a bigger decision than "how to develop this"; OSS is largely software-driven but there are still business concerns. In this case the CodeIgniter Foundation is essentially our "stakeholder" and (though we have a lot of discretion generally) the major release cycle is an area where we have to be attentive. I did push to start version 5 last April with a goal of a December release (to correspond with the dropping of 7.4 from security support) but the reality was we don't have enough contributors to accomplish everything that needs to happen in order to make a major version "count". I still think v5 is our next likely big release after 4.3 (maybe 4.4?) but ultimately that will be more of an empirical decision based on workload versus contributions. The good news? I'm committed to a healthy refactoring process which means as soon as we have a TL;DR we're not there yet but there's a lot of hope for the journey ahead. |
Do we need to add the following methods (except constructor)? $ grep 'public function' system/Validation/ValidationInterface.php | cut -f 7 -d ' ' | cut -f 1 -d '(' > ValidationInterface.methods
$ grep 'public function' system/Validation/Validation.php | cut -f 7 -d ' ' | cut -f 1 -d '(' > Validation.methods
$ diff -u Validation.methods ValidationInterface.methods
--- Validation.methods 2022-09-06 06:50:03.000000000 +0900
+++ ValidationInterface.methods 2022-09-06 06:49:59.000000000 +0900
@@ -1,17 +1,8 @@
-__construct
run
check
withRequest
-setRule
setRules
-getRules
hasRule
-getRuleGroup
-setRuleGroup
-listErrors
-showError
-loadRuleGroup
-hasError
getError
getErrors
setError The following methods seem to be undocumented:
|
If these methods are not documented, they are not in the interface and they are not used by the framework, then maybe they are not needed? |
The above result is on $ grep 'public function' system/Validation/Validation.php | cut -f 7 -d ' ' | cut -f 1 -d '(' | sort > Validation.methods
$ grep 'public function' system/Validation/ValidationInterface.php | cut -f 7 -d ' ' | cut -f 1 -d '(' | sort > ValidationInterface.methods
$ diff -u Validation.methods ValidationInterface.methods
--- Validation.methods 2022-09-06 08:22:47.000000000 +0900
+++ ValidationInterface.methods 2022-09-06 08:22:59.000000000 +0900
@@ -1,9 +1,6 @@
-__construct
check
getError
getErrors
-getRuleGroup
-getRules
hasError
hasRule
listErrors
@@ -11,8 +8,6 @@
reset
run
setError
-setRule
-setRuleGroup
setRules
showError
withRequest |
d7cfb6a
to
8083390
Compare
|
|
Ugh. So much for picking an easy one to start with 😕 What matters at the end of the day:
It is acceptable to have extra public methods on a component class, even if they are documented, so long as we aren't building dependencies around them. So for the method list provided... my guess is that we will need them all but I don't think there is a way to know without tracing back through the uses. One way to do this (I think this is how kenjis started) is to switch all the component class references to the interface (e.g. |
8083390
to
56c7073
Compare
243e559
to
a127d71
Compare
Added these methods in the interface. |
Now $ grep 'public function' system/Validation/Validation.php | cut -f 7 -d ' ' | cut -f 1 -d '(' | sort > Validation.methods
$ grep 'public function' system/Validation/ValidationInterface.php | cut -f 7 -d ' ' | cut -f 1 -d '(' | sort > ValidationInterface.methods
$ diff -u Validation.methods ValidationInterface.methods
--- Validation.methods 2022-09-06 11:12:11.000000000 +0900
+++ ValidationInterface.methods 2022-09-06 11:12:19.000000000 +0900
@@ -1,4 +1,3 @@
-__construct
check
getError
getErrors |
I think the implementation is done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes the implementation looks good to me.
Added the docs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here goes! 😳
Description
Fixes #6224
Alternative #6247
Ref #4356
ValidationInterface::run()
paramValidationInterface::setRule()
ValidationInterface::getRules()
ValidationInterface::getRuleGroup()
ValidationInterface::setRuleGroup()
ValidationInterface::loadRuleGroup()
ValidationInterface::hasError()
ValidationInterface::listErrors()
ValidationInterface::showError()
Validation::loadRuleGroup()
Checklist: