Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105362 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 25554 invoked from network); 23 Apr 2019 17:27:37 -0000 Received: from unknown (HELO mail1.25mail.st) (206.123.115.54) by pb1.pair.com with SMTP; 23 Apr 2019 17:27:37 -0000 Received: from [10.0.1.79] (unknown [49.48.243.98]) by mail1.25mail.st (Postfix) with ESMTPSA id 8E6506055D; Tue, 23 Apr 2019 14:27:55 +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 21:27:52 +0700 Cc: PHP Internals Content-Transfer-Encoding: quoted-printable Message-ID: <91A050D6-0755-4CE4-BE1C-01BDCC618EA1@koalephant.com> References: <9fee0f79-a77d-c0f1-ec24-efa4dd587f91@hristov.com> <71E9312E-C4A6-44EB-AB1C-D8E063EB946A@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:02, Benjamin Morel = wrote: >=20 > It's exactly the purpose of the proposal: avoid this boilerplate. For = the same reason you probably write: >=20 Replacing 1 line of =E2=80=9Cboiler plate=E2=80=9D with a *different* = line of less-obvious =E2=80=9Cboiler plate=E2=80=9D is not an = improvement IMO. > The current proposal is to fill the gap of type checking / type = hinting **inline**, when getting data from an losely typed source. Parameter type hints use syntax that is clear, concise and reasonably = common in other languages. Similarly, defining the type of a variable when it=E2=80=99s declared is = clear and concise reasonably common in other languages. In languages without type hinting (e.g. JavaScript) - the =E2=80=9Cboiler = plate=E2=80=9D you=E2=80=99re trying to remove is also common, e.g. = using `typeof` in JavaScript. 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. 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. The typed properties RFC adopted the same syntax as parameter hints, = even though they have some different implementation details (e.g. you = can redeclare a function parameter to another type, you can=E2=80=99t = with a typed class property). I can see that there would be pros and = cons to either approach for typed local variables - but IMO *that* is = the discussion to have. The initial RFC doesn=E2=80=99t even need to cover every possible = scenario - it could literally just cover plain variable declarations. A = later one could cover adding type hints to for example, foreach. By using syntax that=E2=80=99s already in-use, *and* doesn=E2=80=99t = conflict with other *potential* points of implementation, we can = hopefully end up with more options for type support in the language. Cheers Stephen