Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110743 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 35305 invoked from network); 27 Jun 2020 15:33:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Jun 2020 15:33:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 74F121804C7 for ; Sat, 27 Jun 2020 07:21:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 27 Jun 2020 07:21:59 -0700 (PDT) Received: by mail-wm1-f53.google.com with SMTP id q15so11316428wmj.2 for ; Sat, 27 Jun 2020 07:21:58 -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-transfer-encoding:content-language; bh=0ko8u384VlBastTn2lPQPLCUKyl5btE1ksVLHn4BRLE=; b=IKm+eQwlOrvxpcF9FvVe/TGiGTyo0IXhwEHfc6ChXiRd4P+xLmZkmB8wJiN2azN6kU dw8sQDBPXm//aNNFDNk8Cf7/KiiozyPWJdCWEzfXtuG/uutD1+I8FB+A9DDgYXnv+kQF v44PMeefdcWr26F32alwH52XsoAsK/Q06a5nAA0LoSD7d7o9N9Wj72wousD5OB52KydQ bsHvbs/wJTQ1u2RXA9MGZBVGXOe4O0Wfchq+zYoUr+8OSlVjR7Zsbk1R+U0zLWpLHczz Xh9jheq0YijtHXkD4mh7KPEc+4v+zEjTq4Ess4LRi/8C3s1GV13111KuS5GA5GxhTTOD 2Ytw== 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-transfer-encoding :content-language; bh=0ko8u384VlBastTn2lPQPLCUKyl5btE1ksVLHn4BRLE=; b=r4R3/2AXCbeS1dI+FlNcq5zGUZhwz8zFAqFsygxSTwdbAnWF8i6j07yIAsl16XmWC9 o/59hYoL2V7FBB9eG2PSvodISbvQc967NL1mgfgKa+qi0J4eVOi4MLZqW6oWxCEP1L2u DO0CuiMWkivGCAuSgRQomkAJ6Sg4wvxmorty6hW5C01/ngQU3FiZeoea9S7ng5ipbY41 lmrljE3lIbuYEVHFVv7vahzq2Jya31YxgFNxECifML3jlT4R/HUBQ9eE9+9rgX7p7VYh f5lNR/ElkMPfu+PLjW4q24O3eKyyuk+3JtqK9uQE3kP+CnoBQT5PQJ84MzXvw+XBQDOw D61g== X-Gm-Message-State: AOAM531J5XAIt1DykQ3tN5AEFDAGVn7OvrtfEjBDm3IQw5u9IJ4qRy0x /nzyrFB2HR1OqQ4TrXfZCZPExQsP X-Google-Smtp-Source: ABdhPJzXudVsZ1hmB7rbWRfxYhi3EQ/TeYWhJOVw+JN3bsgPKW2CO4ck9UwRCowZDR8mazLTMrapbg== X-Received: by 2002:a7b:c0c9:: with SMTP id s9mr7940416wmh.166.1593267716183; Sat, 27 Jun 2020 07:21:56 -0700 (PDT) Received: from [192.168.0.22] (cpc84253-brig22-2-0-cust114.3-3.cable.virginm.net. [81.108.141.115]) by smtp.googlemail.com with ESMTPSA id f13sm20062528wmb.33.2020.06.27.07.21.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Jun 2020 07:21:55 -0700 (PDT) To: internals@lists.php.net References: <5ef717ee.1c69fb81.c9b51.794bSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: Date: Sat, 27 Jun 2020 15:21:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <5ef717ee.1c69fb81.c9b51.794bSMTPIN_ADDED_MISSING@mx.google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON From: rowan.collins@gmail.com (Rowan Tommins) On 27/06/2020 10:56, Andrea Faulds wrote: > Of course, if T_PAAMAYIM_NEKUDOTAYIM was never encountered by userland > developers, this RFC wouldn't exist. The thing is, I don't think > T_DOUBLE_COLON should be encountered by userland developers either — > in my view, as an implementation detail, token names shouldn't be part > of parser error messages at all. If we were to remove token names from > the parser errors, we would avoid the problem this RFC seeks to solve. > For most tokens we could simply display the characters it corresponds > to (e.g. "::" for T_PAAMAYIM_NEKUDOTAYIM, which we already do!), and > for those with variable content (e.g. T_STRING) we could display a > human-readable description of what is expected (e.g. "an identifier"). Just to confirm, I am actively working on exactly this, and although slightly delayed by an outbreak of sunny weather, fully expect to have a patch (and, if deemed necessary, RFC) in plenty of time for 8.0. I intend to post a new thread with examples of old and new messages once I've finalised the details. Regards, -- Rowan Tommins (né Collins) [IMSoP]