Generate methodysnopses based on stubs for Zend functions and methods

[kocsismate]

No description provided.

[cmb69]

Thank you for working on this! Highly appreciated.

[nikic]

I scrolled through this, and it looks good to me! Apart from the role="procedural", I didn't spot any errors. @cmb69 Any thoughts?

I think we might want to do a post-processing str_replace to preserve that newline before the final comment, to reduce the amount of spurious diff.

[kocsismate]

I think we might want to do a post-processing str_replace to preserve that newline before the final comment, to reduce the amount of spurious diff.

I'll try to add this to the code.

[kocsismate]

I think we might want to do a post-processing str_replace to preserve that newline before the final comment, to reduce the amount of spurious diff.

I'm afraid this is not that easy. Some pages do the opposite, and doesn't already have a newline before/after the root element tags, so if I tried str_replace(), I would add some new spurious diff. Arguably, much less than currently.

Do you insist on this change, or is it ok if these documents are normalized to get rid of the whitespaces in question?

[Girgias]

I think we might want to do a post-processing str_replace to preserve that newline before the final comment, to reduce the amount of spurious diff.

I'm afraid this is not that easy. Some pages do the opposite, and doesn't already have a newline before/after the root element tags, so if I tried str_replace(), I would add some new spurious diff. Arguably, much less than currently.

Do you insist on this change, or is it ok if these documents are normalized to get rid of the whitespaces in question?

The issue is mostly with translations, as spurious diffs still forces translations to update the EN-Revision tag. So the less the better IMHO

EDIT: Just looked at the current diff, as it seems files already need to be updated the whitespace diffs can be ignored by translations

[kocsismate]

Just looked at the current diff, as it seems files already need to be updated the whitespace diffs can be ignored by translations

Exactly! :)

[nikic]

Is this one ready to go now?

[cmb69]

Pretty good job, @kocsismate! :)

Whether we want to merge as is – well, how thorough do we like to be right now? I left some comments for consideration.

[cmb69]

Assuming these 3 params have not been nullable before 8.0, this would need to be documented (maybe even separate sysnopses for PHP 7/8?).

[nikic]

Whether we want to merge as is – well, how thorough do we like to be right now? I left some comments for consideration.

Please, let's not do any changes, apart from the automated signature changes and anything that is required to keep it building properly (the constructorsynopsis change in this case). We'll get completely bogged down otherwise.

[kocsismate]

@cmb69 Can you please add a label to this PR? Or alternatively, give me right to do so ^^

[kocsismate]

I've just rebased to master, and added a few change log entries where doing so seemed necessary. I also noticed that the manual entries are yet to be added for Stringable and InternalIterator.

[sgolemon]

Generally okay with this (and appreciate the effort!), but in a few spots the parameter names are changed. Some of these are clearly for the better, some are questionable or even for the worse. We should probably update the stubs to make the names match documentation in most cases since the docs were (presumably) written by someone who put editorial thought into the name.

[kocsismate]

@sgolemon Together with Nikita we made quite a lot of effort to improve parameter names. :) Which ones are you not satisfied with?

Unless a parameter name is really broken, I don't think we can change them in the stubs because the arginfo structures are generated from the stubs, so we would introduce a BC break for named arguments.

[sgolemon]

Which ones are you not satisfied with?

The one that stood out to me was handle -> resource. But there are some like class_name to class which I found a little suspect. resource and class are types and I have a small worry that they conflate themselves by default.

Unless a parameter name is really broken, I don't think we can change them in the stubs because the arginfo structures are generated from the stubs, so we would introduce a BC break for named arguments.

Argh... good point. Fine... Leave as-is then. :(

[kocsismate]

I know it's a large one.. But it would be very useful for users. Can you please review it, @cmb69 @kamil-tekiela ?

[cmb69]

Thanks everybody!