Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121378
Content-Type: multipart/alternative;
 boundary="------------DPLN6WtCmBxhTx70jsiweZNs"
Message-ID: <ca0e12bd-daba-4e25-b066-4ffc4b097689@processus.org>
Date: Wed, 18 Oct 2023 13:37:07 +0200
MIME-Version: 1.0
To: autaut03@gmail.com, Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
References: <CAJpLVh1P0kTneo+chFEdp2oCmSKNpgpDxSXd3atv9OHKejABgw@mail.gmail.com>
 <9d5388fa-a5a5-4fa5-81ff-16f6670f80b6@gmail.com>
 <CABigaAULVVGhZCD7bvthZ1NsVc1s8LDsnTS-9=V=APGx=tjbfw@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CABigaAULVVGhZCD7bvthZ1NsVc1s8LDsnTS-9=V=APGx=tjbfw@mail.gmail.com>
Subject: Re: [PHP-DEV] Previous discussions about generics syntax only?
From: pierre-php@processus.org (Pierre)

--------------DPLN6WtCmBxhTx70jsiweZNs
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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


--------------DPLN6WtCmBxhTx70jsiweZNs--