Le 18/10/2023 à 13:01, Alex Wells a écrit :
The community has just now decided on the PHPDoc syntax for generics, has just started widely adopting them in packages and has just got first-party support from PHPStorm. I doubt that migrating to yet another temporary solution (one that still doesn't address all of the concerns) is a good idea right now.
Documentation is not code, and you could have syntax errors within without ever knowing it. Documentation is documentation and static analysis based upon documentation is fragile. All static analyzers may not even be in phase, when you contribute to projects you have to learn code style and conventions, but you also have to learn documenting style and conventions, and you must add the fact that from one project to another, generics documentation convention changes. Even thought you think it's "community decided convention", not all tools are in sync, sadly, and not all the community is OK with it.
I don't use PHPStorm, it's not the only IDE out there, or even people use simple editors sometime. Not all of them will have the same support level regarding "community decided convention". And even worse, most advanced IDE implementation may actually drive the "community decided convention" and steal the "democratic syntax vote" from the community, it's a very bad move where people that make money by selling their IDE may become the one driving the syntax and convention, and which will then en-prison their users in using their IDE, sometime the only supporting the convention they created themselves. OK, it's probably not that true, but at a very theoretical level, it's what it is.
When new syntax elements arise within a new PHP version, all editors, IDE, LSP backends will adopt it immediately, whereas it's definitely not true for "community decided convention". You have one, then two, then some static analysis tool or some IDE adds new subtle changes, new syntax, you never have, and will never have, at any point in time, a situation where all tools are in sync.
I do love the idea to have the syntax at PHP level with type erasure because it's not a "community decided convention" anymore, but a parser syntax that the engine supports which has been discussed and voted for, it is being validated, and exposed in reflection, which makes it resilient, solid, usable, and universal.
Having type erasure eliminates runtime checks, but it still can pose the basis for later real runtime checks. I like the idea even thought I'm not fully comfortable with regarding later feasibility, if the syntax is wrong and things cannot be implemented later in the engine, they the result would be catastrophic (everyone who have used it would have to fix all their code later when another solution would be chosen).
I'm aware this isn't an easy topic, and I have no solution for it. But "community decided convention" is not a solution either, it's at best, some kind of band-aid, and at worst, creating confusion because conventions differs from project to project, from tooling to tooling, and it's terrible for developers.
Regards, -- Pierer
