[Contracts/Deprecation] don't use assert(), rename to trigger_deprecation() #35648
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alcaeus
suggested changes
Feb 8, 2020
7b87979 to
568d594
Compare
fabpot
approved these changes
Feb 8, 2020
|
Thank you for listening :) |
568d594 to
fb09a2e
Compare
yceruto
approved these changes
Feb 8, 2020
jdreesen
suggested changes
Feb 8, 2020
fb09a2e to
0032b2a
Compare
|
Thank you @nicolas-grekas. |
fabpot
added a commit
that referenced
this pull request
Feb 8, 2020
…trigger_deprecation() (nicolas-grekas) This PR was merged into the 5.1-dev branch. Discussion ---------- [Contracts/Deprecation] don't use assert(), rename to trigger_deprecation() | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - This PR is a follow up the discussion that happened in #35526. I applied all the suggestions I received so far on this previous PR so that we can discuss them all together. Here are the changes: - the most important change is to *not* use `assert()` anymore. This fixes the objection from @ostrolucky and @derrabus that deprecations and assert() should not be bound to each other. Instead, in order to still make the function a no-op when wanted, it is suggested that apps declare an empty function. This will be more flexible in practice I believe and keeps all the benefits we envisioned by using assert(); - as suggested by @fabpot, the function is renamed `trigger_deprecation()` instead of `deprecated()`. Because the implementation is now not conditional anymore (from the package pov, since assert() is not used), my arguments to keep the previous name don't stand as strong as before to me so I'm fine renaming. - type hints are added back (requiring PHP 7.1 to use `void`). As mentioned in the 1st point, ppl that really want deprecations to be no-ops will redeclare the function as empty, thus not using any types, thus reclaiming all the perf diff. And for ppl that do want to catch deprecations, the overhead of types is negligible compared to any processing of the deprecations themselves. WDYT? All points can be discussed separately if needed of course. I'm personally fine with merging the PR as is, with all 3 changes. Commits ------- 0032b2a [Contracts/Deprecation] don't use assert(), rename to trigger_deprecation()
|
Thank you very much! 😃 |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a follow up the discussion that happened in #35526.
I applied all the suggestions I received so far on this previous PR so that we can discuss them all together.
Here are the changes:
assert()anymore. This fixes the objection from @ostrolucky and @derrabus that deprecations and assert() should not be bound to each other. Instead, in order to still make the function a no-op when wanted, it is suggested that apps declare an empty function. This will be more flexible in practice I believe and keeps all the benefits we envisioned by using assert();trigger_deprecation()instead ofdeprecated(). Because the implementation is now not conditional anymore (from the package pov, since assert() is not used), my arguments to keep the previous name don't stand as strong as before to me so I'm fine renaming.void). As mentioned in the 1st point, ppl that really want deprecations to be no-ops will redeclare the function as empty, thus not using any types, thus reclaiming all the perf diff. And for ppl that do want to catch deprecations, the overhead of types is negligible compared to any processing of the deprecations themselves.WDYT?
All points can be discussed separately if needed of course. I'm personally fine with merging the PR as is, with all 3 changes.