Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120283 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 59190 invoked from network); 15 May 2023 13:08:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 May 2023 13:08:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 485BE180083 for ; Mon, 15 May 2023 06:08:00 -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=-0.6 required=5.0 tests=BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE 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-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 15 May 2023 06:07:59 -0700 (PDT) Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-965c3f9af2aso1950681666b.0 for ; Mon, 15 May 2023 06:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684156078; x=1686748078; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=P581EYZrojrAdRxE5houJnL46D7lGklMaWmdzTWk6Ik=; b=RiXGd6LvDzrzwfAV5IYlNgQRvtscvK72FQKV3VmbjHM+gq1OCZSTPjTXbFtbrmzujh Jut00vdQYtPzQD6EZo/IXRX3pnKLy1YzqRtPHP8hJK8ge8cMujU6QURcmiOLQpnXIDT/ cLmX/EZH8d7UquAlMUdmvRiHvCf9zXzpqgoXZcznLxHQ+iB2XtmOUYs8wGPa+P5JoG0B yVmUvGDrUkBeiKXw4qX2gpMUP1Ce1W07rVBG6GUx7gyKpg910f1Dkb2uCzoC/sK3AHmL 7NZQvjDmGIkftQkRpolwksZjzjT2vs8gknB5b1waFyUcIjfbRIGpHJl1cGJ6DhA7ZqKu W2Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684156078; x=1686748078; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=P581EYZrojrAdRxE5houJnL46D7lGklMaWmdzTWk6Ik=; b=SLa6jRBWRujzxFDZp169i5gqDnhZfal9DZPkTCNNN3yN033mmb9x5NS66wDYC3RNne eTGGdccGyo0Z6sb0I8o9tLfGDVBpR60odA2dpxIlokJ2CfVi//JLHHCHirYY5NulRRAF dDGT5JCCkNdfVLLjrO49eb7IS6ZnymBsnzquAo9AyFeCLH7tMbgDoCzkR1ddAvtIEZG/ ifs2zlWhqNy/OwNvBFLvv7MFAfa1hnBfsfGwU5WTOjW1OBnNMxvCn5h4v65+p7htL5Vi UYAIIMAYoNhD2xuzyEmMVaXJ5qHWa3QF2S6p9pfXax3grnGIYvwCkNtBa5ok+XiMqwTY SVYw== X-Gm-Message-State: AC+VfDwr9UC03B5SIbgahVFgVB+ZJBWmoEUq2tastR/YgA8BeDUYS7nu jBJGpWKcNwDCENUlfPSwyVeblschXNNJ/bDooexAWhRxJjU= X-Google-Smtp-Source: ACHHUZ4mpq2Y2COoSvIWSbaXtFiIv/0x3KDZWPfE2byYMhQtx/UOIZCUK3adgnOWn/1Qe5RKuggkjOi/r8sq5sqhyWk= X-Received: by 2002:a17:907:7f1f:b0:966:550f:9bff with SMTP id qf31-20020a1709077f1f00b00966550f9bffmr26563083ejc.59.1684156077818; Mon, 15 May 2023 06:07:57 -0700 (PDT) MIME-Version: 1.0 References: <436378BB-FDFA-43BD-A633-C030C347E683@gmail.com> <359D9C64-52A5-4BF5-91B5-72F7CE116F78@gmail.com> In-Reply-To: Date: Mon, 15 May 2023 15:07:31 +0200 Message-ID: To: PHP Developers Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] [Discussion] nameof From: flexjoly@gmail.com (Lydia de Jongh) (I hope it is ok that I take parts from several mails) Op za 13 mei 2023 om 12:37 schreef Rowan Tommins : > On 13 May 2023 10:04:39 BST, Lydia de Jongh wrote: > > >I prefer a magic constant like `::name` instead of a function call as it > >can be used in a wider scope; for example as a parameter in an Attribute= . > > Don't confuse the syntax with the implementation: "::class" isn't actuall= y a constant, and the proposed "nameof()" isn't actually a function; both a= re just syntaxes understood by the compiler to generate strings according t= o certain rules. The RFC explicitly mentions use in attributes: Just got that from the php manual.... =F0=9F=98=9C : as it is listed under = the 'magic constants' (https://www.php.net/manual/en/language.constants.magic.php) But I understand your point. > > The one part of the RFC that surprised me was this: > > > > > When getting the name of constants and functions, the name will NOT b= e the full name, but the lexical name. This means that if the name is use'd= , it will be that name. However, if the full name is used in the nameof(), = the full name is returned. > > > > No reason is given *why* it works this way, and expanding the namespace= s on a name is one of the most useful features of "::class". Importantly, i= t means that the string created can be passed to other contexts, and still = refer to the same thing. Op zo 14 mei 2023 om 14:55 schreef Rowan Tommins : > > On 14 May 2023 11:59:13 BST, Robert Landers wr= ote: > >use function \Path\To\Function\Serializer\to_json as json_serializer; > > > >// a bunch of code using json_serializer() > >throw new Exception('json_serializer returned invalid json'); > >// or > >throw new Exception('\Path\To\Function\Serializer\to_json returned > >invalid json'); > > I can see your reasoning now, but I can think of arguments both ways roun= d: if you're trying to find out *why* the function returned invalid JSON, y= ou need to know where the source code for that function is, so need its ful= ly qualified name. > > My gut feel is still that it's more often useful to have the expansion do= ne for you, but maybe others have different perspectives. > Op zo 14 mei 2023 om 17:45 schreef Robert Landers : > > > Conversely, namespace imports are entirely local to the current file (o= r even a namespace{} block), and it's almost impossible for running code to= see anything other than the expanded name. > > > > That doesn't mean that there aren't good reasons to have nameof() handl= e both things in the way proposed, I just think those reasons are probably = different for the two cases. > > That's a fair point. Maybe it is worth putting it up for a secondary > vote? I do have a strong preference, but I'd rather have full names > than no names, and doesn't change the RFC that much. If I'm > understanding correctly, it would only affect first-class callables > and constants. > I totally agree with Rowan. In many (most?) cases you need the fully qualified name. Even or especially for error handling! Of course mostly the error is somewhere else. But you want to know the starting point. An unqualified name gets you nowhere. Although backtrace can help you out. And this is also consistent with how ::class or get_class() work.... it gives fully qualified names. On the other hand you could argue that 'nameof()' in itself means: 'just looking for the direct/unqualified name of something' and is an addition to ::class and get_class().... Then we still need something to get the fully qualified name/path of a variable or php-item. For a class we have: ::class, get_class() and class_exists(). And inside these function you can use: get_class(MyClass::class); For a method we only have: method_exists and it needs 2 parameters, for the methodname: only string is possible =F0=9F=98=AD Would be nice to have, and consistent to have: - MyClass::method::method - method_exists($object->method::method) - get_method(MyClass::method::method) And the same for properties: - MyClass::property::property - method_exists($object-> property::property) - get_method(MyClass:: property::property) The downside is that we get many new 'magic constants'... What about: - for unqualified names: -- nameof(any-php-item) -- any_php_item::nameof - for fully qualified names: -- pathof(any-php-item) or fullnameof() -- any_php_item::pathof or ::fullnameof > > To put things into a more productive context, then, I think a useful im= provement to the RFC would be some examples of how you would use it with th= e different supported types, showing why the proposed semantics are useful = for those scenarios. > > I can do that for sure. Aside for error handling, I think it would give attributes a boost as they handle configuration and metadata, without having a proper way to address variables and other php items, except classes. #[MyAttribute(property: MyClass::myProperty::fullnameof)] Which IMHO is much better then: #[MyAttribute(property: callback(nameof(MyClass::myProperty))] and if it only gives the unqualified name: #[MyAttribute(property: MyClass::class . callback(nameof(MyClass::myPropert= y))] Which also shows that it is not consistent..... with the useful working of ::class > ... > #[SomeAttribute(callback: nameof(\Acme\bar(...))] > ... This callback to nameof()..... is really terrible =F0=9F=98=A3=F0=9F=98=A3 Is this not why ::class was invented, while get_class() does the same?! Op zo 14 mei 2023 om 00:42 schreef Robert Landers : > I think the downside of using ::name would be: 'what if I already have > a const called "name"?' > > So, we'd have to come up with a different name. Largely, as far as the > compiler would be concerned, we've both got the same idea. Good point. I hope my suggestions above do help. And that you consider adding them to your RFC =F0=9F=99=8F > > instead of > > $class =3D new ReflectionClass(ClassName::class); > $property =3D $class->getProperty('property'); > $type =3D $property->getType(); > var_dump($type); > It is worse.... you need an extra if with ->hasProperty.... > Something to think about... Greetz, Lydia