Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100549 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29936 invoked from network); 12 Sep 2017 19:43:49 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Sep 2017 19:43:49 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.54 as permitted sender) X-PHP-List-Original-Sender: smalyshev@gmail.com X-Host-Fingerprint: 74.125.83.54 mail-pg0-f54.google.com Received: from [74.125.83.54] ([74.125.83.54:34325] helo=mail-pg0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D7/A7-10715-3F838B95 for ; Tue, 12 Sep 2017 15:43:47 -0400 Received: by mail-pg0-f54.google.com with SMTP id j16so12853823pga.1 for ; Tue, 12 Sep 2017 12:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=fdtyQInjsB6wQni/E21Atz1flR2hVnf0H7jrQhYofcg=; b=l6f/7PMpwb/6IZMbTyR74+97vztKTxrR9fp8oNy8gWm3PSZpL+aAT3GsECED+uXCYn Qlyn6hCWy6K2vaG0slEDJxcSq99+oRzrA0NIsF6NQYc5Nvoadi2B6nxYAwyLSSFV6e+f Tc1M3PpgXVCxiweHpr1+e9XxsIO+4nXvQMkHtlpjfG1mwmDpDydx8+cyJoEFOtXzQs72 XJ52szWdIeH3ByQ7Px5ARulgh6LWkkIN2yVXEyqMJ54s7ozMB1qeoJqU8rlp55dQz5K9 2jcF40+YM0WEaylD8e4T6l9jtzxYS5OPNnJj3CPCdwVVZ1v2eYYcWxSz/wiKrZcwkuPt inGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fdtyQInjsB6wQni/E21Atz1flR2hVnf0H7jrQhYofcg=; b=LJayv9uF0eoindpuBd4Pk3evDujMtpBLlN1vr2XqDgC33iBHfO6QVg/2GPoYu+kE0m Gy4gskFB0qSxCKksjOA7jg59VPNkO8iNkhBn1PD1q2KC5lIyf6/EweyBos4KqQCOV7n0 omfn7pvgU5eIW8+KFIomwHY+PBs0dJjyej8s/TGVmQ2n0Xal4B3ealEvyvycbiLzlGyl kneixBjrD/6IlACMMiol00S3RT+PSWN5e3RHFD1nHRKLt9t/effvpODNPczGJqmjBz7x einfLAdWGIntMw/uKCLhipvCxVtZEZn4tIiDTAYxT0QNZ/7JHmE1B6IV8CHS1C8RlmA4 iv/w== X-Gm-Message-State: AHPjjUhK1Vwtc0E9Jo+pIrpEfpT+LT+uZM8/dgMjfAcQkI4Te2sWErqj UksckaSibGqJB2CHEog= X-Google-Smtp-Source: ADKCNb5PBWC2tyZ+spukvZF37ShwAMMbnvyjK2OLF2K4iSvvGyrqsT438zkeKO3ssK7c1D58ZkYSbA== X-Received: by 10.99.125.25 with SMTP id y25mr15737994pgc.45.1505245424503; Tue, 12 Sep 2017 12:43:44 -0700 (PDT) Received: from Stas-Pro-2016.lan (108-233-206-104.lightspeed.sntcca.sbcglobal.net. [108.233.206.104]) by smtp.gmail.com with ESMTPSA id m5sm4429952pfg.12.2017.09.12.12.43.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 12:43:43 -0700 (PDT) To: "Christoph M. Becker" , "internals@lists.php.net" References: Message-ID: <5a9001ea-2a3c-8ea6-d5ef-1da326009414@gmail.com> Date: Tue, 12 Sep 2017 12:43:42 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Deprecate and remove case-insensitive constants? From: smalyshev@gmail.com (Stanislav Malyshev) Hi! > case-insensitive constant. This feature appears to potentially result > in confusion, and also causes bugs as shown in > . See an example created by Nikita to see > some probably unexpected behavior: . The latter case probably should be fixed by not allowing second constant to be defined. If you already have case-insensitive constant, it should cover all of those. > Even if these issues could be resolved, I still think allowing both > case-sensitive and case-insensitive constant identifiers does more harm > than good, so either case-sensitive or case-insensitive constant > identifiers should be removed from the language. Since case-sensitive > constant identifiers are already the default, and HHVM doesn't even > support case-insensitive identifiers at all, I would suggest to remove > case-insensitive constant identifiers. I don't think HHVM not supporting something can be an argument. I'm worried about TRUE vs. True vs. true though - I've see all of those used around the code (not tRuE though ;) and breaking that would add a ton of meaningless work to maintainers without any upside. Same with NULL/null etc. I am also not convinced those constants are really that bad. I'd probably be fine with phasing out manual defines for case-insensitives though. But I'm not sure what purpose it would serve then - the engine would still have to support it, no? -- Stas Malyshev smalyshev@gmail.com