8000 [Yaml] removed deprecation notices on internal constant by fabpot · Pull Request #13325 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[Yaml] removed deprecation notices on internal constant #13325

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

Merged
merged 1 commit into from
Jan 8, 2015

Conversation

fabpot
Copy link
Member
@fabpot fabpot commented Jan 8, 2015
Q A
Bug fix? no
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets antonioribeiro/tracker#56, #13306
License MIT
Doc PR n/a

Reverting the deprecated notices on Unescaper::ENCODING for two reasons:

  • The constant is only used internally and nobody ever used it anyway;
  • The deprecation notice is ALWAYS triggered when using the YAML component.

@nicolas-grekas
Copy link
Member

👍

@fabpot fabpot merged commit faeed58 into symfony:2.7 Jan 8, 2015
fabpot added a commit that referenced this pull request Jan 8, 2015
…(fabpot)

This PR was merged into the 2.7 branch.

Discussion
----------

[Yaml] removed deprecation notices on internal constant

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | antonioribeiro/tracker#56, #13306
| License       | MIT
| Doc PR        | n/a

Reverting the deprecated notices on `Unescaper::ENCODING` for two reasons:

 * The constant is only used internally and nobody ever used it anyway;
 * The deprecation notice is ALWAYS triggered when using the YAML component.

Commits
-------

faeed58 [Yaml] removed deprecation notices on internal constant
@Tobion
< 8000 /summary> Copy link
Contributor
Tobion commented Jan 8, 2015

Hm, I did not find where Unescaper::ENCODING is accessed internally?! Could you pinpoint me please?

@fabpot
Copy link
Member Author
fabpot commented Jan 8, 2015

@Tobion That's the irony :) This constant is not used anymore and nobody should ever have used but still, everyone were having a deprecating notice just because the class was loaded.

I could have removed the constant altogether, but just in case someone somewhere is using the constant for whatever reasons, I prefer to keep it until 3.0.

@Tobion
Copy link
Contributor
Tobion commented Jan 8, 2015

But @nicolas-grekas introduced the constant deprecation via a new class because he said the class is only loaded when the constant is actually accessed (lazy class loading). That was the whole idea. So it doesn't actually work?

See #12968 (comment)

@fabpot
Copy link
Member Author
fabpot commented Jan 8, 2015

Right, apparently, that does not always work. So, all the other constants that were using the same mechanism should be checked to see if that works correctly. We are already aware that some do not work, and me or @nicolas-grekas is going to fix them.

@Tobion
Copy link
Contributor
Tobion commented Jan 8, 2015

Well, either we can rely on lazy constant resolution by php or not. If it only works for some and some not, it would not be deterministic and not be reliable as well to work in the future. Then we would need to remove all of these forms of constant deprecations warnings.

@stof
Copy link
Member
stof commented Jan 8, 2015

I think it might depend on the optimization level of OPCache. If it is configured to optimize the access to constants, it might need to load them eagerly

@fabpot fabpot deleted the yaml-fixes branch January 9, 2015 18:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0