Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85107 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53237 invoked from network); 16 Mar 2015 23:49:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Mar 2015 23:49:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@golemon.com; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=php@golemon.com; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.217.176 as permitted sender) X-PHP-List-Original-Sender: php@golemon.com X-Host-Fingerprint: 209.85.217.176 mail-lb0-f176.google.com Received: from [209.85.217.176] ([209.85.217.176:32808] helo=mail-lb0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 68/A2-34940-D0C67055 for ; Mon, 16 Mar 2015 18:49:34 -0500 Received: by lbbzq9 with SMTP id zq9so41955223lbb.0 for ; Mon, 16 Mar 2015 16:49:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IJNtj7SP6KDPWiC8ex1+mzM7Rvb/0G9tYsAX20ZQbQU=; b=DqyM2jl0oD91Tpty3jocrHE8dJ+DHo52fVO1ZDuekm9oUra7AZkJAOdiq/yQ+mTYe7 UNWntH502moB6/bRhtUbhqKF5a+JRfmACMTGwSuxx7279qD8XWsqF2uZcQ61Zv+kC9MQ Qil9D06ykdD3j3Ym8BObcvdEZNkme6KvBrsshw0xbVfA43s2sOmXeHK6fqGQ8aCzjLmZ eI78KdvwfA4+cy34v+9JVaoozrxcu3oEDtnoEmYg7bI6lDj+IZZUAgnzKiGLbt0xlI0Q kBUb/YWnHZ9u6Iql5W0rYAMKNdCMKFv6pu1HdJVCI+BAdBn+tPVnZBavpGtSG1Qipivn HbGw== X-Gm-Message-State: ALoCoQn7NtvCJUEfwhMqVXsBtz9/HG+BsOmdvkL3dxVVDQCSrjq7fB/NwxAUPUti00yftTR6w/g4 MIME-Version: 1.0 X-Received: by 10.152.28.5 with SMTP id x5mr56523100lag.112.1426549771202; Mon, 16 Mar 2015 16:49:31 -0700 (PDT) Sender: php@golemon.com Received: by 10.112.38.73 with HTTP; Mon, 16 Mar 2015 16:49:31 -0700 (PDT) X-Originating-IP: [2620:10d:c082:1055:22c9:d0ff:fe87:295b] In-Reply-To: References: Date: Mon, 16 Mar 2015 19:49:31 -0400 X-Google-Sender-Auth: 7TlILNRESsP5TF6C-m52rwmhs68 Message-ID: To: Dan Ackroyd Cc: PHP internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [VOTE] Reserve even more type hints From: pollita@php.net (Sara Golemon) On Mon, Mar 16, 2015 at 7:37 PM, Dan Ackroyd wrote: > On 16 March 2015 at 06:44, Sara Golemon wrote: >> The voting period for the "Even More" type hints reservation RFC is now open. >> > > There's been a little bit of traffic on the list in the past few days; > I don't think your RFC has received enough cogent discussion. > I can't force people to talk about something. Especially something so minor while the war-of-the-century is being waged. > In particular the keywords 'Resource' and 'mixed' seem to have limited > need to be reserved. I don't believe there has been any suggestion > that either of these would actually be used as types for PHP 7.x. So > making them be unusable seems to be a large BC hit for no gain for > people who currently have classes that use them > To be clear, this RFC is about declaring these names as reserved, not about actually /using/ them. There's no language in the RFC about actually throwing errors or other code-breaking behavior. Therefore, even should all of them pass, it does *NOT* mean that your code using these names suddenly stops working on PHP7. It means that you have been warned that using the names of intrinsics is a bad idea, and that the language reserves the /right/ to make doing so an error at some point in the future. > Can anyone please make a strong argument for why 'resource' and > 'mixed' should be reserved, if we currently have no plans to use them? > In the case of "resource", because it refers to a real type in PHP's type system. Using that intrinsic as an arbitrary label is a bad idea. It'd be like putting your project's code in the PHP namespace. There's nothing in the language preventing you from doing so, but it's a bad idea. Formalizing that it's a bad idea is what this RFC does. As far as "mixed"... I don't have a strong reason for it. TBQH, I'm not strongly in favor of all of these supplemental types. but they're included for completeness, and presented as individual voting options for flexibility. -Sara