Skip to content
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

Adding/Removing methods that exist in the supertype #68

Open
tomzx opened this issue Jun 24, 2015 · 0 comments
Open

Adding/Removing methods that exist in the supertype #68

tomzx opened this issue Jun 24, 2015 · 0 comments

Comments

@tomzx
Copy link
Owner

tomzx commented Jun 24, 2015

Note: WIP

This is a rather important aspect of semantic versioning, as the presence of a method in an ancestor class can reduce the impact of a change. For instance, we currently assume that removing a method implies a major change, while it might only mean that this method has moved to one of its ancestors.

Visibility (public, protected, private) applies to classes/interface/trait methods.

Classes

Code Level Rule
---- ----- - Added
VXXX PATCH -- Public
VXXX PATCH -- Protected
VXXX PATCH -- Private
---- ----- - Removed
VXXX PATCH -- Public
VXXX PATCH -- Protected
VXXX PATCH -- Private

Interfaces

Code Level Rule
---- ----- - Added
VXXX PATCH -- Public
VXXX PATCH -- Protected
VXXX PATCH -- Private
---- ----- - Removed
VXXX PATCH -- Public
VXXX PATCH -- Protected
VXXX PATCH -- Private

Traits

Code Level Rule
---- ----- - Added
VXXX PATCH -- Public
VXXX PATCH -- Protected
VXXX PATCH -- Private
---- ----- - Removed
VXXX PATCH -- Public
VXXX PATCH -- Protected
VXXX PATCH -- Private

To support this, we would be unable to simply scan the files that do not match and would have to do a complete scan of the source code in order to establish class hierarchies. Furthermore, this would mean that in the event that some supertypes are not available, we may only be able to do a partial analysis.

What we can do is first to detect files that have changed, then only load their parents as necessary, instead of scanning all the source code. This may be achievable by assuming that the code follow PSR-0 and that we can find an SPL autoloader somewhere that will take care of loading the classes we need as necessary. In case no such SPL autoloader exists, then we will do a full source code scan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant