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

Improved ReflectionType API so that a target reflection class can directly be retrieved, removed existing named constructor #415

Merged
merged 9 commits into from
Apr 17, 2018

Conversation

Ocramius
Copy link
Member

…e found, removed existing named constructor
use RuntimeException;
use function sprintf;
Copy link

@roukmoute roukmoute Apr 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it really needed?
Tests passes without this.

In the RFC, there is this text: While it's true that you can import a namespace and alias it to a single character, this is not necessary for classes, so it makes no sense to require it for functions.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gonna likely propose the adoption of doctrine/coding-standard here, which enforces all functions to be imported to avoid static analysis issues, as well as runtime function lookups.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, just seen that there already is an open pull request for that.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok thanks :)
It's interesting point of view.

For to avoid static analysis issues is it not a problem from static analysis?
And for function lookups I don't understand where is the problem with that.
Have you an example? To help me to understand where it could be a problem.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you call a function foo() you have no idea if it's a function declared in the same namespace or a global function. PHP falls back on the global scope for functions and constants whereas you never have the ambiguity with classes: you either need to use the FQCN e.g. \Closure or import the symbol with a use statement use Closure

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For to avoid static analysis issues is it not a problem from static analysis?

an example I have is this one:

namespace Potato;

define('POTATO', 'POTATO');

Is Potato::POTATO defined here? Or is define() a user-defined function?

You can only be sure of it if it was written this way:

namespace Potato;

use function define;

define('POTATO', 'POTATO');

I hope that clears it up.

UPGRADE.md Outdated
@@ -4,6 +4,13 @@ This document serves as a reference to upgrade your current
BetterReflection installation if improvements, deprecations
or backwards compatibility (BC) breakages occur.

## 4.0.0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why not to make it part of version 3?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just thought 3.0.0 was already released: did this in a real rush, so will amend 👍

@asgrim
Copy link
Member

asgrim commented Apr 16, 2018

Apart from whatever is causing failed build, looks ok at a glance

Ocramius added a commit to Roave/BackwardCompatibilityCheck that referenced this pull request Apr 16, 2018
Ocramius added a commit to Roave/BackwardCompatibilityCheck that referenced this pull request Apr 16, 2018
@Ocramius
Copy link
Member Author

@asgrim all green here 👍

@asgrim asgrim merged commit f9b2041 into master Apr 17, 2018
@asgrim asgrim deleted the feature/reflection-type-target-class-fetching branch April 17, 2018 21:34
Ocramius added a commit to Roave/BackwardCompatibilityCheck that referenced this pull request Apr 18, 2018
@Ocramius Ocramius changed the title Improved ReflectionType API so that a target reflection class can be found, removed existing named constructor Improved ReflectionType API so that a target reflection class can directly be retrieved, removed existing named constructor May 26, 2018
uzibhalepu added a commit to uzibhalepu/BackwardCompatibilityCheck that referenced this pull request Aug 6, 2024
uzibhalepu added a commit to uzibhalepu/BackwardCompatibilityCheck that referenced this pull request Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants