Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105365 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 48291 invoked from network); 24 Apr 2019 08:27:12 -0000 Received: from unknown (HELO mail1.25mail.st) (206.123.115.54) by pb1.pair.com with SMTP; 24 Apr 2019 08:27:12 -0000 Received: from [10.0.1.79] (unknown [49.48.243.98]) by mail1.25mail.st (Postfix) with ESMTPSA id B3F4F604A5; Wed, 24 Apr 2019 05:27:40 +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: Wed, 24 Apr 2019 12:27:36 +0700 Cc: PHP Internals Content-Transfer-Encoding: quoted-printable Message-ID: References: <9fee0f79-a77d-c0f1-ec24-efa4dd587f91@hristov.com> <71E9312E-C4A6-44EB-AB1C-D8E063EB946A@koalephant.com> <91A050D6-0755-4CE4-BE1C-01BDCC618EA1@koalephant.com> 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 21:54, Benjamin Morel = wrote: >=20 > @Stephen Reay >=20 >> In languages without type hinting (e.g. JavaScript) - the =E2=80=9Cboil= er plate=E2=80=9D > you=E2=80=99re trying to remove is also common, e.g. using `typeof` in = JavaScript. >=20 > It's also very common to *not* check types in JavaScript... I assume = the > absence of type hints is partly responsible for this, and a reason why > quite a lot of JS developers turn to typed preprocessors, such as > TypeScript. >=20 >> Assigning a variable to itself, because you want to check its type is = the > weirdest concept I=E2=80=99ve heard in a long time. >=20 > I assume you're speaking of the foreach() example; sure, used this = way, it > looks like a self-assignment, but in most cases it's not, it's an = inline, > checked type-hint: >=20 > // (assuming the 'as' syntax, now that the cast syntax has been = buried) > $foo =3D $entityManager->find(User::class, 123) as User; >=20 > You're effectively adding, **inline and with just a few chars**, an > additional type-hint and runtime check to the value. I wouldn't call = this a > no-op. >=20 >> You want to add more capability to enforce type checking - I get = that, > and I share that goal. But when we already have pretty common, = intuitive > syntax to do so in one situation, I don=E2=80=99t see why you = wouldn=E2=80=99t adopt the > same syntax elsewhere. >=20 > While I don't agree with you on many points, I appreciate that we = share the > same goal somehow, and hope that we can find common grounds. I would > personally not be against variables typed on declaration, but even = though > this probably does not make sense, I'm somehow more comfortable with: >=20 > function test(string $name) { > $name =3D 123; > } >=20 > than: >=20 > string $name =3D 'Ben'; > $name =3D 123; >=20 > I guess that I could be more comfortable with this approach if we had = a > switch, such as `declare(locked_types=3D1)`, that would enforce the = type of > the variable throughout its lifetime. This may come at a huge runtime = cost, > though. >=20 > - Ben Hi Ben, I realise type checking in JS is not really common, my intention was to = indicate that the suggested `$foo =3D $bar->foo() as Foo` is basically = unheard of in any language besides Hack. As has been suggested and = refuted many times - less code is not necessarily more readable. In this = case, I still feel `$foo instanceof Foo || throwTypeError()` or even a = 3-liner `if` to do the throw inline, is more readable and more obvious = than the proposed syntax. Yes - because of the syntax you=E2=80=99re proposing, this feature could = never realistically be added to `foreach` statements without making them = hard to read at best, and possibly (I don=E2=80=99t know, I=E2=80=99m = not familiar with the C internals) impossible. Given that type hinting the members of an iterable is something that has = been discussed and rejected before, the ability to hint types of an = iterable is a no-brainer to me. It=E2=80=99s also one of the two = examples Larry came up with. As I understand it, you find `Foo $obj =3D $bar->getFoo();` to imply a = fixed type for the variable $obj? I=E2=80=99ll just recap one more time, and then I=E2=80=99m not going to = repeat this, because it=E2=80=99s surely getting boring for everyone = else on the list. There is (as of 7.4) precedent for a typed =E2=80=9Cvariable=E2=80=9D = that *is* locked to the type it=E2=80=99s declared with (class = properties^), and for typed variables (function parameters) that are = *not* locked to the type they're declared with. If this feature were = added, it surely will follow the behaviour of one of those two: either = they are or are not a fixed type, and one of the three cases will become = the =E2=80=98exception=E2=80=99 developers need to remember when using = typed variables/properties. ^: Yes I know class properties aren=E2=80=99t really the same as local = variables, but they=E2=80=99re presented very similarly in syntax and = behave mostly the same pre-7.4 I *assume* implementation wise it=E2=80=99s not even realistic to make = local variables behave as 7.4+ typed class properties do (i.e. fixed = type), but my point is that from a =E2=80=9Cdo people want this=E2=80=9D = point of view, I believe the people who are actually likely to declare = types on local variables, are *probably* quite unlikely to re-declare = variables to a different type like that in most cases anyway. I=E2=80=99d also suggest that just adding local variable type hinting = =E2=80=9Cnow=E2=80=9D (i.e. in 8.0 if an RFC passed) in a manner = consistent with function parameter type hints, would mean that a later = discussion/RFC could approach the concept of fixed-type variables (e.g = using a `declare` option as you mentioned). Cheers Stephen