Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120270 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 55821 invoked from network); 14 May 2023 12:55:19 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 May 2023 12:55:19 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2D7F51804AA for ; Sun, 14 May 2023 05:55:18 -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, 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-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 ; Sun, 14 May 2023 05:55:17 -0700 (PDT) Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-3075e802738so10725527f8f.1 for ; Sun, 14 May 2023 05:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684068916; x=1686660916; h=content-transfer-encoding:mime-version:message-id:references :in-reply-to:user-agent:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=Mh4JIr7P5mYz4RWtt6P+nzT9WU/KiCM5SMpQeJhbElM=; b=AsFGfZi9/FpE1yncz3p9FWsxXLvx/UTlatmap2j36hbdgl1snqfGikLFIjKBmglN5O F3gZNr32C3Lgkh7DGgi5h3JNT9mWD4I8rr8v/mKih5rAhdRIz6iQ51TeE/jkkQyH7tyO cVM3YDJJQ0dJIrSbwjh8WiqN68WqOmLhsvu2MptYuoqCGjdKpV/0lIlmzbaNXX/zRBSY ducG9mmhNV/NuhREO+SrSo1EHEClGaIPhsedBY9uck7O5xfGfW0eD7+a7JpeccDpIDfJ 0M954kYEZUOBPSTetlSCuMmz6fbj6dobvR0CKZiOaFjx+Bh2rTXn6tBP7AtwtglL6upJ fpfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684068916; x=1686660916; h=content-transfer-encoding:mime-version:message-id:references :in-reply-to:user-agent:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Mh4JIr7P5mYz4RWtt6P+nzT9WU/KiCM5SMpQeJhbElM=; b=OX3jdO+qMG3WaNxvy2ebiz+bRCw8dkv9g64E/9CoMi7W6ZSTVrCsK872E1wYUVIiwN Xgz5UaVpLTkyCE0Y5rR+4jGWyGTY+uBnqJB1D2F/rxVmeXCNwPxuVHfF72XsFPZg+ltY YXM8wmNLBikGV1pOoqCOw6ykpdVdF4o6gl3pJsg00DUag/xiIyNtzrRgHIAbf9ZSW/5Q egZO3j+QkrAe3vypwZFG7zM7kLMs7+ESrPl0Y58rP1OzOHuKMBcs8qmK4H5CG7w2U9IN 11dAvVenh32GWDiliVwsaopnSBRMDBAwB+h1P5BCqxNscoerJBgDTxMx3hyujSbMihY0 h5Sw== X-Gm-Message-State: AC+VfDzcAHnrKxWU6eebFka6BIxzT5NC1RQvT83vwQkx0IKpoQElk+cB /5kr476Z5+mbLelZSRCTtdk= X-Google-Smtp-Source: ACHHUZ7CZmIl7ZuxC3VcSSHscVkO4vdy27zaRxYm9A6Q/I5ltIhEXt9T1Z0mjlLsa7cjlHvdVYil7Q== X-Received: by 2002:adf:f492:0:b0:307:a36b:e7b1 with SMTP id l18-20020adff492000000b00307a36be7b1mr15163231wro.5.1684068916068; Sun, 14 May 2023 05:55:16 -0700 (PDT) Received: from [127.0.0.1] (cpc83311-brig21-2-0-cust191.3-3.cable.virginm.net. [86.20.40.192]) by smtp.gmail.com with ESMTPSA id e15-20020adfe38f000000b00307b5376b2csm13779091wrm.90.2023.05.14.05.55.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 May 2023 05:55:14 -0700 (PDT) Date: Sun, 14 May 2023 13:55:13 +0100 To: Robert Landers CC: internals User-Agent: K-9 Mail for Android In-Reply-To: References: <436378BB-FDFA-43BD-A633-C030C347E683@gmail.com> Message-ID: <359D9C64-52A5-4BF5-91B5-72F7CE116F78@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] [Discussion] nameof From: rowan.collins@gmail.com (Rowan Tommins) On 14 May 2023 11:59:13 BST, Robert Landers = wrote: >As someone who has had limited interaction with the engine code itself >but has been using PHP, daily, for nearly 15 years, I'm not sure this >technical distinction makes sense in the context of programming in >PHP=2E When using traits, I don't think of it as 'inserting code', but >rather I think of it as 'using code' -- you do use `use TraitName` >after all and it is very similar to the top-level using statement=2E I don't think it's a technical distinction at all, it's part of the defini= tion of traits in PHP, which are often described as "compiler assisted copy= and paste"=2E The methods from the trait are added to the definition of th= e class during compilation, and after that it is almost impossible to disti= nguish them from methods written directly in the class definition=2E=20 Conversely, namespace imports are entirely local to the current file (or e= ven a namespace{} block), and it's almost impossible for running code to se= e anything other than the expanded name=2E That doesn't mean that there aren't good reasons to have nameof() handle b= oth things in the way proposed, I just think those reasons are probably dif= ferent for the two cases=2E >> Can you give an example of such an error message that would want to exp= ose the local alias? > >Which error message helps in resolving the error and would be written >by someone writing the code? To clear up any doubt, there was no sarcasm or aggression intended, I was = genuinely requesting an example, which you have provided, so thank you=2E >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 round= : if you're trying to find out *why* the function returned invalid JSON, yo= u need to know where the source code for that function is, so need its full= y qualified name=2E My gut feel is still that it's more often useful to have the expansion don= e for you, but maybe others have different perspectives=2E >This would also be weird in the case of constants/functions in the >global space, because fully qualified names begin with a "\" which >feels unnatural when reading things meant for humans (such as error >messages)=2E This seems to be a common sentiment indeed - people prefer long lists of "= use function" to \ prefixes=2E It's not something I personally find unnatur= al, any more than "/images/logo=2Epng" or "/etc/hosts", but I'm willing to = concede I may be in a minority there=2E >> Not really, I'm afraid=2E If I have to write out the fully-qualified na= me, why would I bother with nameof() rather than just using a string? > >If you write it in a string you really will, actually, have to write >out the fully qualified name because an IDE won't know you're >referencing a language construct and be able to autocomplete it for >you=2E If you rename the function or remove it, you won't be able to use >static analysis to locate these strings, you'll have to manually >search-and-replace the codebase, which opens up space for human error=2E This makes some sense, although static analysis tools and IDEs already do = a lot with pseudo-types in docblocks to understand the expected values of s= trings=2E The biggest weakness of a generic "nameof" is that it still doesn't hint w= hat kind of thing you want to mention=2E >IMHO, this comment isn't constructive or helpful, how can I help you >understand? I'm more than happy to answer any and all questions, but >comments like this are pretty demoralizing when there are only a few >people discussing the feature in a community I'm relatively new to I'm genuinely sorry you felt this way, and it was absolutely not my intent= ion to criticise you=2E If anything, it was meant to be an admission of my = own failings, that I'd come into the discussion with the wrong preconceptio= ns, because the use cases which immediately came into my head seemed to hav= e contrasting requirements from the ones that you intended=2E To put things into a more productive context, then, I think a useful impro= vement to the RFC would be some examples of how you would use it with the d= ifferent supported types, showing why the proposed semantics are useful for= those scenarios=2E On a different note, you've talked about how errors would be handled for n= onexistent constructs, but given PHP's dynamic nature, there's also a quest= ion of *when* they would need to exist=2E For instance, assuming we go with= Warnings, if I use nameof(Foo::bar), and class Foo is defined in a differe= nt file, there's a few things that could happen: - the resolution happens while compiling a single file, in which case it w= ill always give a Warning, because any symbol outside the file is unknown - the resolution happens at runtime, and causes class Foo to be autoloaded - the resolution happens at runtime but doesn't trigger autoloading, so wh= ether it gives a Warning or not depends on whether other code happens to ha= ve loaded the definition of Foo - probably other options that I haven't considered With the "no error handling" version, this becomes moot, because it's just= a string manipulation exercise=2E That's how ::class currently works, apar= t from a few specific cases like static::class and $someInstance::class Regards, --=20 Rowan Tommins [IMSoP]