I think some collection of community-approved attributes might be beneficial for PHP.
I’m thinking in terms of attributes like `#[Internal]` that might not make sense to add directly to the language but would be good to have so that static analysis tools and IDEs could standardize on them (like with phpdoc annotations).
Is this something @phpfig would take on? If not them, who?
"Users can provide both encoded and decoded query characters. Implementations ensure the correct encoding as outlined in getQuery()." —UriInterface, PSR-7
If I'm building a library that uses PSR-7 interfaces, how do I know whether I can provide encoded or decoded query characters to the implementation, since my library doesn't know what implementation(s) it's dealing with?
OMG! WTF kind of AI abomination is this?!
I've made a few small changes to this draft and have updated it to 0.2.1. It's only been 2 years and 4 months since the 0.1.0 draft. 😳
Maybe I should try to do something with this, like approach #PHPFIG about it. I'm just not sure I have the energy to do much more than present a draft.
Hey #PHP. When you use union and intersection types, do you include spaces?
(RT for reach, etc. This is survey data for @phpfig. If you know of any official policies by major projects already, please note/link in the replies.)
@jrf_nl Do you know of any phpcs sniffs that implement the newer #PHPFig PER Coding Style 2.0?
In particular, I'm thinking about: “If a function or method contains no statements or comments (such as an empty no-op implementation or when using constructor property promotion), then the body SHOULD be abbreviated as {} and placed on the same line as the previous symbol, separated by a space.”
And the similar rule for classes.
How does a screen reader read a hashtag that includes an acronym and a pronounceable word, like #PHPFig? I would say this as “P-H-P fig,” for example. How does a screen reader read it? I’d like to make my hashtags as accessible as possible.