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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[80999] Fix count TypeError not documented #556

Merged
merged 6 commits into from Apr 29, 2021

Conversation

thinkverse
Copy link
Contributor

This PR adds the TypeError count() now throws to the changelog, and also updates the example showing that PHP 8.0 throws a TypeError instead of emitting and E_WARNING.

First time adding to a changelog, so not 100% sure if the versions are displayed in descending order or ascending. 馃聽 Will change if requested.

Copy link
Member

@saundefined saundefined left a comment

Choose a reason for hiding this comment

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

Thank you! Descending order is used

@cmb69
Copy link
Contributor

cmb69 commented Apr 29, 2021

It might make sense to split the error cases from the example to their own example, and then have three <screen>s introduced with &example.outputs;, &example.outputs.72; (this entity needs to be defined in language-snippets.ent), and &example.outputs.8. Maybe that would be overkill, though.

@thinkverse
Copy link
Contributor Author

thinkverse commented Apr 29, 2021

@cmb69 is that how you wanted it? Never messes with <screen>s and &example.outputs before, so I used foreach.xml as a base. Those are the expected outputs, at least based on the given test example; https://3v4l.org/mMgYD

@cmb69
Copy link
Contributor

cmb69 commented Apr 29, 2021

Yes, that's basically what I meant (you can remove the "as of PHP ..." comments now). But it may also make sense to split the example, so that the good cases (the first two var_dumps()) and the bad cases (the last two var_dumps()) have their own examples. This would make it possible to have a single &example.outputs; for the good case, and maybe to add some words regarding the bad behavior example.

@thinkverse
Copy link
Contributor Author

Should the "bad example" example be after the good example then, or should it be added after the recursive example? Cuz count has two examples, the first deals with both a good case and a bad case, the second deals with the recursive aspect of count.

@cmb69
Copy link
Contributor

cmb69 commented Apr 29, 2021

I'd put the bad example right after the good example.

@thinkverse
Copy link
Contributor Author

I'm a bit lost on how to "add some words" about the bad example, the title might be enough - I looked around the repo and found a doc using this general idea. Might be OK and get the point across? Otherwise, I'm not sure how to add some words. Can you add notes in or between examples? Those usually go after examples, at least from what I've noticed during my years of looking at the documentation. 馃

@cmb69 cmb69 merged commit a7663ad into php:master Apr 29, 2021
@cmb69
Copy link
Contributor

cmb69 commented Apr 29, 2021

Thank you very much!

@thinkverse
Copy link
Contributor Author

Glad to help. 馃憤

@thinkverse thinkverse deleted the add-count-typeerror branch April 29, 2021 13:25
mumumu added a commit to php/doc-ja that referenced this pull request Apr 29, 2021
* Add TypeError to changelog
* Update example for count to show TypeError
* Split example outputs into separate PHP versions
* Split examples into good and bad examples

Closes php/doc-en#556
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.

None yet

3 participants