Sync some classsynopses with stubs

[kocsismate]

[haszi]

@haszi are the ID changes for the class constants an issue for linking?

Unfortunately they are. Class constant IDs are linking to their declaration only if they are in the classname.constants.constant_name format and non-class constants in the constant.constant_name format.

[kocsismate]

Ah, it has just come to my mind what the initial problem was: since these classes are called the same way as the extension, the ID on the global constant page collides with the class constant list ID. E.g. in case of FFI, both are ffi.constants...

Do you have an idea what the solution could be? I guess the most disruptive one is to use a different pattern for either global constants or class constants, like class-name.class.constants.constant-name... But I hope there's a solution which requires less changes.

[Girgias]

I'm confused?

Surely a non-class constant cannot conflict as the former must be constant.ffi.constant_name and for the class ones it is ffi.constants.constant_name or am I missing something here?

[kocsismate]

Surely a non-class constant cannot conflict as the former must be constant.ffi.constant_name and for the class ones it is ffi.constants.constant_name or am I missing something here?

Not the ID of the constants themselves, but the ID of the constant container (?) collides. See https://github.com/php/doc-en/blob/5837fedc3f29cc3ab04b22171f6890a294a2f8df/reference/ffi/constants.xml#L4. and https://github.com/php/doc-en/blob/5837fedc3f29cc3ab04b22171f6890a294a2f8df/reference/ffi/ffi.xml#L64 That's why I had to override the class constant IDs.

[Girgias]

Could we maybe just remove that file and appendix? If the extension doesn't provide any constants I'm not sure it is super useful to have the page in the first place?

[kocsismate]

Could we maybe just remove that file and appendix? If the extension doesn't provide any constants I'm not sure it is super useful to have the page in the first place?

That may work in these specific cases, but we should rather solve the general issue I think 🤔 because the generator should produce valid code

[haszi]

That may work in these specific cases, but we should rather solve the general issue I think 🤔 because the generator should produce valid code

IDs of classes are already in the class.class_name format so maybe the sections within these elements could use the class.class_name.section_name format (e.g. class.ffi.constants for the constants of the FFI class).

Edit: Jut to clarify: I'm strictly referring to the IDs of the containing elements (e.g. <appendix>, <section>) and not the constants' (ie. <varlistentry>'s) IDs as making the latter change to all classes would be a massive undertaking.

[kocsismate]

Just to clarify: I'm strictly referring to the IDs of the containing elements (e.g. ,

) and not the constants' (ie. 's) IDs as making the latter change to all classes would be a massive undertaking.

Yes, I'm all for going with the fix which requires the least amount of change, but unfortunately, as far as I remember, the constant IDs have to start with the container ID. 🤔 Let me check if this is still the case.

[kocsismate]

Let me check if this is still the case.

Looks like, it's not 🥳 I'm not sure what I remember about, maybe I just mixed up something.

[haszi]

Could you drop the leading and trailing hyphens from FFI::__BIGGEST_ALIGNMENT__'s ID? Leading and trailing hyphens were dropped from IDs as suggested here and here (and implemented in PhD here).

[kocsismate]

There are a few properties which start with a double hyphen, like SoapClient:: $__soap_fault. Do we want to remove them as well or are we fine with them?

[kocsismate]

@haszi I updated gen_stub to generate the correct fieldsynopsis IDs: https://github.com/php/doc-en/pull/3367 (I can remove the property related change if we don't need it)

[haszi]

There are a few properties which start with a double hyphen, like SoapClient:: $__soap_fault. Do we want to remove them as well or are we fine with them?

Since we already removed them from constant IDs and they aren't part of the method IDs either, I think it would make sense to remove them from all IDs. From a quick look (grep -rE 'xml:id=".*(__|--|\.-|\._).*"'), there are only 29 of these in doc-en anyway.

[haszi]

I think this looks good, @haszi can you confirm?

Looks good to me.