Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105349 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 25541 invoked from network); 23 Apr 2019 12:18:44 -0000 Received: from unknown (HELO mail1.25mail.st) (206.123.115.54) by pb1.pair.com with SMTP; 23 Apr 2019 12:18:44 -0000 Received: from [10.0.1.79] (unknown [49.48.243.98]) by mail1.25mail.st (Postfix) with ESMTPSA id E186160510; Tue, 23 Apr 2019 09:18:50 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) In-Reply-To: Date: Tue, 23 Apr 2019 16:18:46 +0700 Cc: "M. W. Moe" , sebastian@php.net, lemon.head.bw@gmail.com, Marcos Passos , PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: <438D9C5B-5B03-4BEB-A094-1C2D4954094C@koalephant.com> References: <899de214-607e-9ad8-80cb-eeda5adf8ee6@php.net> To: Benjamin Morel X-Mailer: Apple Mail (2.3445.104.8) Subject: Re: [PHP-DEV] Object Type Casting Reloaded From: php-lists@koalephant.com (Stephen Reay) > On 23 Apr 2019, at 16:03, Benjamin Morel = wrote: >=20 > > I like the idea but I find the syntax (both suggestions) less than = great, given that there=E2=80=99s already =E2=80=9Censure a type=E2=80=9D = syntax, and both suggestions are already used for other things (casting = and foreach) >=20 > Note that we already use `as` in other contexts than foreach: in = imports (`use Foo as Bar`) and in traits (`use SomeTrait { foo as bar; = }`) , so I think that reusing the keyword for yet another use case is = OK, as long as it does not conflict. >=20 > > Is there some reason (eg ambiguities) a type can=E2=80=99t just be = placed before a variable to ensure a type, similar to a function = parameter or typed property?=20 > > string $foo =3D 'bar'; > > ... > > I=E2=80=99m talking about exactly the same functionality that exists = with method parameters - constraining the type it must conform to when = it is declared. Nothing more nothing less. >=20 > I would personnally read this as "this variable is now strongly typed, = INCLUDING later assignments" (which would belong to another feature / = discussion), but as you have later clarified that this is not what you = had in mind, I think that this syntax is then even more confusing than = the other proposals: >=20 > Foo $foo =3D new Foo(); > $foo =3D 123; // this would work? >=20 > > Using `as` means trying to add type constraints to an iterable in = the foreach would be ridiculously confusing: > > foreach ( $foo as $K as int =3D> $v as string) {...} >=20 > Please note that my proposal is specific to class/interface names, not = other types for now (I could consider broadening it if people are = interested in the suggested "as" syntax from Hack). > Anyway with the two syntaxes suggested so far, you would not inline it = in the foreach, but explicitly write: >=20 > foreach ($foos as $foo) { > $foo =3D (Foo) $foo; > // or > $foo =3D $foo as Foo; > } >=20 >=20 Hi Ben, My objection to `as` is that it specifically prevents (or makes very = confusing) the `foreach` use I mentioned. There=E2=80=99s no variables = involved in imports/traits, and neither of those relates to foreach. As for the `string $foo =3D $bar->getFoo();` =E2=80=98looking strongly = typed=E2=80=99 and wondering if it will allow re-declaration - do you = think the same when you see `function (string $foo) { $foo =3D = explode(=E2=80=98 =E2=80=98, $foo); }` ? Functions have allowed type = hints since 5.0 - nearly 15 years ago, and nobody seems to be confused = if those variables can be redeclared. Whether you *should* redeclare = them to a different value is something you need to decide for yourself. As for limiting this to class/interface names - why would you do that? = It took YEARS to get scalar type hints for function parameters, why = would you not include them from the start on anything new that pertains = to essentially the same functionality? I can=E2=80=99t even begin to comprehend how re-assigning a variable to = itself (even if it is a no-op internally, it *appears* to re-assign) to = do a type check seems like a good option. Cheers Stephen=