Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:114547 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 81435 invoked from network); 20 May 2021 20:45:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 20 May 2021 20:45:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3E05D1804B5 for ; Thu, 20 May 2021 13:55:07 -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=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (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 ; Thu, 20 May 2021 13:55:06 -0700 (PDT) Received: by mail-qt1-f181.google.com with SMTP id g8so6336707qtp.4 for ; Thu, 20 May 2021 13:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=r/f+1lOH8z/O+H+xN4XtMwFSkpKRzLafY0gVHjhyBVM=; b=DZtqICHYIpfzWu4mTk0yuP+enZpTv+var1+Gdsa3N0XyB7X5AYyKWg3RnvF/539jvk kS3kFFqjEOS/KOwbn0+zamsQb+KBFg+8aM+x8ZW+6VJMm7FASFkDRSOF/QFKBkghxB68 0unRBChwMVVChO8VxLKpGAK4Nr3/EDT61CHzDDDBcRrlRFtYVthLN2Xe+AB5Ot3O2/Tx MHKv8sTrfvcXNnTzQD8A449aQ0rN9SLSCkAe6KlRhtlyBkO3wMHSmbs4rSa1PEtCM4Kr yncJ2juZhZRI6C2ykyGbnaNh+Nef9IrKUtpb7/KnASBp00f4qSz8nnYi3KQobBs+/tRu UxCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=r/f+1lOH8z/O+H+xN4XtMwFSkpKRzLafY0gVHjhyBVM=; b=Cd2qtIbDhMFlLHJf1rCPsHNoXrvTC3/5cLkKETOujw/el84v39bY5rtc4b34GqCBch +oFPJkA4Xi6H5Mj9oUqZSwzB3O+A9/ANYzjGCJb3jTAnp78qSdzHJj8Y3APnmlWD5NL0 CvpkryY5LBBfYHq/bXtZX3yW+djYbOzxHlTeTUifyJ84eoJuU5R/CxIv+49UFhEhbHyA BUQXCUB9y25sbgZWGzojWkgWEPIQ0kca8GbLap8EKM0VaZkPYimnFJpK6DmIi6SvDd+g ztqRVOu/VGxgkeswik60R0X1o3rZFGT2vF/K4LANO7lVGSAoEFdPSYLbOI3GhSnF2ODN hSUA== X-Gm-Message-State: AOAM530xhYTYik3SVLuNu0LSL+vXMgK5Z93oX2PBE92CyRWNtd1VwmBp oF0gAiYoLuG9yF98g5Zbh18sXpqkGQ2kjy7c/6815wQh88QzYA== X-Google-Smtp-Source: ABdhPJywXkVUpk+cv5s5gnU6vrEM+KEDrTcwWVMFbR0jyKvpclUXcsHqS5aDcXZQTFLWoV05jRReUS+WA1eb9u/ondI= X-Received: by 2002:aed:30c2:: with SMTP id 60mr7496395qtf.245.1621544103395; Thu, 20 May 2021 13:55:03 -0700 (PDT) MIME-Version: 1.0 References: <1a024ec2-60c0-4a48-5f1e-4a4369a6a642@gmail.com> In-Reply-To: <1a024ec2-60c0-4a48-5f1e-4a4369a6a642@gmail.com> Date: Thu, 20 May 2021 21:54:52 +0100 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="00000000000045428205c2c92820" Subject: Re: [PHP-DEV] [RFC] First-class callable syntax From: tekiela246@gmail.com (Kamil Tekiela) --00000000000045428205c2c92820 Content-Type: text/plain; charset="UTF-8" Hi Nikita, I would like to just express my feelings. It's a definite YES from me for first-class callables. We need something to replace [$this, 'privateMethod']. I just don't like the proposed syntax. The triple period '...' has a meaning already and reusing the same syntax isn't nice. I haven't followed the PFA RFC closely, but I don't like that proposal as it seems to add additional complexity to PHP's syntax for little gain. I feel like it's just arrow function on steroids. I know we can already do something like this: function do_stuff($e) { return $e**2; } $result = array_map(do_stuff::class, [1,2,3,4]); I wouldn't mind having a dedicated operator for creating closures in the same way. e.g. $result = array_map(do_stuff::closure, [1,2,3,4]); I understand that ::class creates a string literal and ::closure creates closure, but from the usability point of view, they would be used in similar ways. Many languages have shared symbol tables for constants, functions and variables. PHP doesn't, so we can't just use the name, but I agree with Rowan that just using a function's name would be ambiguous even if the parser allowed for that. We could introduce new syntax for this. I think Kotlin uses double semicolon in front of the identifier. e.g. $result = array_map(::do_stuff, [1,2,3,4]); This would be less confusing than the (...) syntax IMHO. Of course this still has the same ambiguity as Rowan points out. Is ::$objA->methA a property or a method? We could solve this problem by specifying the syntax to always refer to methods/functions. Parentheses could be used to enforce access to property, e.g. ::($objA->methA) would evaluate the value stored in the public property of the object $objA If we land on using the syntax as your RFC proposes then I would ask Internals to avoid (...) and instead use another symbol inside the parentheses. I believe any other symbol would look better than triple period, e.g. $objA->methA(*) Kind Regards, Kamil --00000000000045428205c2c92820--