-
Notifications
You must be signed in to change notification settings - Fork 22
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
Contract propagation #9
Comments
Sorry, I'm going to sleep now, can discuss tomorrow. In short: this is doable in runtime, we just take our method, then recursively ask for prototype method or for parent class, then take our annotations and just run them all. |
Cya. To read tommorow - I am wondering if goaop/framework could help us or we have to do it manually with pure reflection mechanism. |
@pdaw I think PhpDeal otherwise, can handle this specific job pretty nice by looking at parent methods and querying annotations from them, so all contracts from the parent classes will be applied too. As DbC is development-only tool (it's recommended as a best practice, no contract checks in production mode), this reflection API shouldn't be a performance killer (can be pre-cached in array like this Class::method => array of contracts) |
I get it, may you tag it as enhancement? |
I think it can works in two modes:
It would be handled with some extra annotation, ex. @contract\Override. Default version may be the second one. |
H! There are rules for applying DbC contracts for inheritance (these rules are based on Liskov principle):
So, for all Ensure and Invariant annotations we MUST collect all parents annotations and check them. If we have some more postconditions in the current class, they should be verified as well. But we SHOULD check if the parent method defines exactly the same contract to execute it only once. For Verify annotations we should take them only from the current class and run them, no checks for parent contracts. In this way we can give an ability to weaken them. But we SHOULD check special cases for all possible |
Thanks for your full and detailed answer :) I'll try to implement it in free time. |
Closed in #10, released in 0.4.0 |
I wonder if we could inherit contacts from parent classes.
For example, we define an interface with common contract and all children (without own contract) would be obligated to fulfills parent's requirements.
I'm not sure if it's possible with goaop/framework.
The text was updated successfully, but these errors were encountered: