Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120534 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 55548 invoked from network); 6 Jun 2023 14:06:12 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 6 Jun 2023 14:06:12 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B984F180382 for ; Tue, 6 Jun 2023 07:06:08 -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=-3.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE, 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-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (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 ; Tue, 6 Jun 2023 07:06:08 -0700 (PDT) Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-4f62cf9755eso2516320e87.1 for ; Tue, 06 Jun 2023 07:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wikimedia.org; s=google; t=1686060366; x=1688652366; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=aLafDJhNo655Pyp+kkQG/+ijqSIFy7uNQ4cgy4gSvq0=; b=m1vjTUpxLrLEz2/+qLBCdWb14DHnQTAcTg+QUbARKkS2GxXtHZjHuJq/JDvTPRK/S+ H387crePnCOp4bZuM5ncYfW9Vs6wofRL9GyF4d7XsWTbUun/4P7N9UcsGaa9Dprpi06X EGQsurLDAKGLG2icWKtu8jLpcnW4bk229qXKQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686060366; x=1688652366; h=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=aLafDJhNo655Pyp+kkQG/+ijqSIFy7uNQ4cgy4gSvq0=; b=YqEUFYDV7VbL09ep15+Ntc3CHJQIB/iOvZ2+3Hyjw9ziEma2VZUcdMA4mlQVADV0mf j8mA7PPYmjRItsPCzEoz9Bm/xH8gEP8hCI+iE15j1FqMVEakpZsfIo2j9qEGSy6J1kIe h6Cn+SiGQf07CGtHo0gJAD2UsVtkSOAl4aChZnS3V3UuKnX/z/JQS5VrRphtoDLlR1nw zDf/JJp5rRGMPN2Gzd9ZmrDsUuqJMpxokxW/GemETt/1fVNdiNZ6T+efsP8sX5Ollh3c IyOxVLZSohkg2t52tWLDBM6sOMVUb449xaAWbjqCML5aD2sQg2jjbKT89pxs5vL1oGZl Vdbg== X-Gm-Message-State: AC+VfDwnkxxUSgzgoT35n9QDxGcof3gDzZnZdTZfGt5ywMBJEAtMhlE0 rCa9PRXCl6VfS2WdADJn2Ui0LAtTyvrvs+wpw4KhKSE1BfQz7KH3 X-Google-Smtp-Source: ACHHUZ7W7TWvoBD9ZuDjIiG6ABYfuYzg8/oShmRifV80vOq85XN8a2pE95/FoTvzyU2JQKyyfu8MBL+MxBtzCK9wSnA= X-Received: by 2002:a19:f806:0:b0:4ee:dafa:cb00 with SMTP id a6-20020a19f806000000b004eedafacb00mr1046570lff.60.1686060366298; Tue, 06 Jun 2023 07:06:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 6 Jun 2023 15:05:55 +0100 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000345f1505fd7685a2" Subject: Re: [PHP-DEV] RFC [Discussion]: Closure self-reference From: ttijhof@wikimedia.org (Timo Tijhof) --000000000000345f1505fd7685a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 5 Jun 2023 at 05:09, Alexandru P=C4=83tr=C4=83nescu wrote: > > How about a keyword/variable to the current executing closure that works > also if you refactor it to a function or a method. > Just like self for a class we can have a keyword like fnself [..] This seems quite appealing to me, and is imho more idiomatic and ergonomic than the other proposals. Keywords naturally avoid conflicts with user variables, and remove the need for each author to pick a name for their closure and the inevitable preferences, automation, and disagreements that will arise from that. On the other hand, we've seen from *match()* how disruptive a new keyword can be as they clash as well, with function names instead of variables. Building on an existing keyword or soft-reserved naming convention would avoid that. In terms of global constants, we have double underscores which is in the proposal already but feels unnatural as others have indicated already. In terms of local constants, I believe we authors generally prefer uppercase names, and we have one built-in special constant that's lowercase: *self::class*. Perhaps *self::fn* or *self::callee*? The latter borrows the closure terminology form JavaScript (arguments.callee, which does the same thing). -- Timo Tijhof https://timotijhof.net/ --000000000000345f1505fd7685a2--