Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121400
MIME-Version: 1.0
References: <CAJpLVh1P0kTneo+chFEdp2oCmSKNpgpDxSXd3atv9OHKejABgw@mail.gmail.com>
 <9d5388fa-a5a5-4fa5-81ff-16f6670f80b6@gmail.com> <CAJpLVh39RUuqPKp=B4LJGfsVhZNHQGQFVTBcmgdyuJffmRvzPg@mail.gmail.com>
 <CADK1yX+4gVp9BcfydEgW-RpvpCUcAK8+bBQomfWPbnfaxtm_wA@mail.gmail.com>
In-Reply-To: <CADK1yX+4gVp9BcfydEgW-RpvpCUcAK8+bBQomfWPbnfaxtm_wA@mail.gmail.com>
Date: Wed, 18 Oct 2023 17:37:53 +0200
Message-ID: <CAPzBOBM5-KE16oy_2VRS0UFe_K+n2BNZ8zze5v-v1C1d-p2CWA@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: =?UTF-8?Q?Olle_H=C3=A4rstedt?= <olleharstedt@gmail.com>, 
	Rowan Tommins <rowan.collins@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Previous discussions about generics syntax only?
From: landers.robert@gmail.com (Robert Landers)

On Wed, Oct 18, 2023 at 3:47=E2=80=AFPM Deleu <deleugyn@gmail.com> wrote:
>
> On Wed, Oct 18, 2023 at 4:14=E2=80=AFAM Olle H=C3=A4rstedt <olleharstedt@=
gmail.com>
> wrote:
>
> > 2023-10-17 21:39 GMT+02:00, Rowan Tommins <rowan.collins@gmail.com>:
> > > On 16/10/2023 15:08, Olle H=C3=A4rstedt wrote:
> > >> Hello internals,
> > >>
> > >> Was there a previous discussion about the pros/cons of adding only t=
he
> > >> syntax needed for generics, but not the functionality? So static
> > >> analyzers could use it, instead of docblocks. I looked at externals.=
io
> > >> but couldn't find anything specific.
> > >
> > >
> > > Hi Olle,
> > >
> > > Since I haven't seen it expressed quite this way in the previous
> > > discussion, I'd like to highlight what I think is a major downside to
> > > this approach, at least as commonly proposed:
> > >
> > > Using the same syntax for type information that is guaranteed to be t=
rue
> > > (existing run-time checks) and type information that is "advisory onl=
y"
> > > (new checks for optional static analysis) means users can no longer h=
ave
> > > confidence in that type information.
> > >
> > > This is one of the interesting things about the compromise over scala=
r
> > > types - if you see a declaration "function foo(int $bar) { ... }", yo=
u
> > > *know* that $bar will be an int at the start of every invocation of t=
hat
> > > function, regardless of which mode the calling code uses. I think add=
ing
> > > exceptions to that certainty would be a bad direction for the languag=
e.
> > >
> > > On the other hand, I can see a "third way": if the problem with curre=
nt
> > > static analysis conventions is that they have to be parsed out of a
> > > string-based docblock, we can provide *dedicated* syntax, without
> > > unifying it with the standard type syntax. For instance, some of the
> > > earlier discussions around introducing attributes suggested reflectio=
n
> > > expose the AST of the attributes arguments, rather than the resolved
> > > expressions, allowing them to act a bit like Rust's "hygienic macros"=
.
> > > If that was added as an optional mode, you might be able to do someth=
ing
> > > like this:
> > >
> > > #[RawAttribute]
> > > class GenericType {
> > >      public function __construct(AST\Node $typeInfo) { ... }
> > > }
> > >
> > > function foo(#[GenericType(int|float)] array $foo) {
> > >      // array is the type guaranteed by the language
> > >      // static analysis libraries can get the GenericType attribute f=
rom
> > > reflection and receive an AST representing the type constraint int|fl=
oat
> > > }
> >
> > Not sure readability is improved here compared to existing @template
> > annotations. ;)
> >
> > Olle
> >
>
> I won't be participating much about this discussion because I lack
> expertise to add too much. I just wanted to voice a small (and defeated)
> minority of PHP developers that don't want/care for Generics. I've been
> working with Typescript lately and I see generics only being useful for
> library code and even then when I end up writing some valid Generics stuf=
f,
> Typescript verbosity becomes so bloated that it invalidates the added-val=
ue
> of the functionality.
>
> I truly can't understand how Generics is the most requested PHP feature s=
o
> I will just assume I will have to live with it one day, but mixing it wit=
h
> Attributes Syntax seems to be a recipe to make it as bad (or worse) than
> the experience of using Generics in Typescript.
>
>
> --
> Marco Deleu

I also agree with Marco. Generics are a pain in the rear in languages
that have them. Usually, the PHP version of the same code written in
generic C# or Typescript is much more concise and clear. The only
exception to that, would be built-in arrays. If there is exactly one
thing that could be "generic", it would be those that. Effectively, a
simpler syntax to this:

function onlyStrings(string ...$strings): array { return $strings; }

onlyStrings(...['array','of','strings']);

I'd be thrilled if I could just write:

function onlyStrings(array<string> $strings): array<string> { return $strin=
gs; }

onlyStrings(['array','of','strings']);

That is all I want whenever I think of Generics in PHP. The rest is
just complicated fluff in my humble opinion.

Robert Landers
Software Engineer
Utrecht NL