Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83320 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44231 invoked from network); 20 Feb 2015 16:25:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Feb 2015 16:25:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=robin@kingsquare.nl; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=robin@kingsquare.nl; sender-id=pass Received-SPF: pass (pb1.pair.com: domain kingsquare.nl designates 141.138.142.202 as permitted sender) X-PHP-List-Original-Sender: robin@kingsquare.nl X-Host-Fingerprint: 141.138.142.202 spring.kingsquare.nl Linux 2.6 Received: from [141.138.142.202] ([141.138.142.202:49421] helo=spring.kingsquare.nl) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 08/B4-14173-EFF57E45 for ; Fri, 20 Feb 2015 11:25:35 -0500 X-No-Relay: not in my network Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by spring.kingsquare.nl (Postfix) with ESMTPSA id 1257F77C004 for ; Fri, 20 Feb 2015 17:25:31 +0100 (CET) Received: by lbiz11 with SMTP id z11so7277787lbi.8 for ; Fri, 20 Feb 2015 08:25:30 -0800 (PST) X-Received: by 10.112.62.135 with SMTP id y7mr9280208lbr.50.1424449530894; Fri, 20 Feb 2015 08:25:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.5.2 with HTTP; Fri, 20 Feb 2015 08:24:54 -0800 (PST) In-Reply-To: References: <04db01d04cc1$d9925770$8cb70650$@php.net> Date: Fri, 20 Feb 2015 17:24:54 +0100 Message-ID: To: internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Re: [RFC] Reserving More Types in PHP 7 From: robin@kingsquare.nl ("Kingsquare.nl - Robin Speekenbrink") Hi, First of all I'd like to see this (clean) RFC formalized / ratified sooner rather than later. Just to chime in here from a user / framework developer perspective in regards to *double* / *real* / *boolean* / *integer* reservation: i'd like to see these aliases (and the is_*-functions etc) be deprecated / removed sooner than later instead of kept around. It's minor, i know, but consistency wins above a quick find/replace above all. With lesser roads to the destination (rome), the easier the route to follow ;) Atleast have it on a roadmap somewhere instead of keeping it around and in every discussion with regards to reserved keywords, typehints, return types etc etc Thanks and keep up the good work ! (can't wait to see what PHP7.0 will actually bring to the table) Thnx, Robin Speekenbrink 2015-02-20 17:11 GMT+01:00 Andrey Andreev : > Hi, > > On Fri, Feb 20, 2015 at 6:00 PM, Levi Morrison wrote: >> On Fri, Feb 20, 2015 at 4:21 AM, Andrey Andreev wrote: >>> >>> Agree on 'double' though ... if we want to discourage its usage, we >>> might even think of deprecating it. >> >> While deprecating it might be a good course of action, it is out of >> scope of this RFC. I personally think that reserving it is a good way >> to discourage its use: simply reserve it and then don't use it for >> anything. If we decide not to use the aliases if we have scalar types >> and the aliases are reserved this would prevent users from making >> custom types from the aliases. In my opinion this a Good Thing. > > Well, I meant to deprecate is_double(), is_real() and the > corresponding explicit casts. I might be missing other places when > they are used, not sure, but the point would be to stop using these > names for scalar types at all, so that everybody can freely use them > for class/trait/interface names ... I don't think anybody would do > that only for pseudo-scalar hinting objects. > > So, while yes - that's outside of this RFC's scope, reserving them as > keywords would be the opposite of what I had in mind. > > Cheers, > Andrey. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >