Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108499 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 3814 invoked from network); 11 Feb 2020 21:57:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Feb 2020 21:57:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9D66418053B for ; Tue, 11 Feb 2020 12:11:55 -0800 (PST) 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.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS,SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 116.202.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (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 ; Tue, 11 Feb 2020 12:11:54 -0800 (PST) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 058FA601EB; Tue, 11 Feb 2020 20:11:53 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freedom.nl; s=default; t=1581451912; bh=kHygpekiDWBeAe8UQ30oCxDVDGpkxbCKX0k4HIXLYKo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Esmo+Ybhby8+rCXPJBk8otKWMXrkYv71Le0fExqCM+fK6B4RVuI+na3q7L8U/fRjS OPmJodOdxSdQFOIJ2iRpPtH2MN2uHW0qDN/cDJ12OzoDz98tBKVsWvGxMjDlD88i8a MscU+SgyAIXcONNasQJHq9HcFT0Uj2YDCZbqlz7Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freedom.nl; s=default; t=1581451913; bh=kHygpekiDWBeAe8UQ30oCxDVDGpkxbCKX0k4HIXLYKo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=a8CHuefsxiZv32g8H2aG3LaMtOGe4N0RAy7dOJoXp/CtIeYPoOQFqlsF0NjA+F2Nl TRhMBjSsGTv443LIdLc234kCuloCrjBoe8HaZSxa14FJUIgeDSI+SQQGmxkcTsOwgN SGzEtER//iR25V/ux2VP/iuwAs9tsYTubHj7nTfY= To: Dan Ackroyd Cc: PHP internals , Larry Garfield References: Autocrypt: addr=d.h.j.takken@freedom.nl; keydata= xjMEXimHTRYJKwYBBAHaRw8BAQdAzvRUI24yOGvteVk9N6VKIt425fNgg0P1rvD2WQLGP+fN JERpayBUYWtrZW4gPGQuaC5qLnRha2tlbkBmcmVlZG9tLm5sPsKtBBMWCAA+FiEEvtrj9qG2 TA2YmjvLhef0X6cSlpAFAl4ph00CGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA IQkQhef0X6cSlpAWIQS+2uP2obZMDZiaO8uF5/RfpxKWkPywAQChh9Z1jSvitkT3sIipwMlk dnUlYY5Ue3lHBBhF6pQUOwD/XtEz/fsjvqE/GpjJhXpxNodwKjLhaUiFe9qRwwH/5QXOOARe KYdNEgorBgEEAZdVAQUBAQdAMNSCUI0PnOjjrFKZDAFRQzKLVDCINuFNgsXh0snmlUwDAQgH wpUEGBYIACYWIQS+2uP2obZMDZiaO8uF5/RfpxKWkAUCXimHTQIbDAUJCWYBgAAhCRCF5/Rf pxKWkBYhBL7a4/ahtkwNmJo7y4Xn9F+nEpaQEYUA/2mZ3uEN0JTRUZbxHGBMB4IhQw0cdIML FpFrTycqUCXCAQD5rWXomBWVD/DRHk7O3KjNsek9F1DEZgGeZ5pPmNF/Dg== Message-ID: <605d93e9-87be-e985-4a52-c99ac217f441@freedom.nl> Date: Tue, 11 Feb 2020 21:11:49 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Virus-Scanned: clamav-milter 0.102.1 at c03mi01 X-Virus-Status: Clean Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] From: d.h.j.takken@freedom.nl (Dik Takken) On 11-02-2020 20:20, Dan Ackroyd wrote: > On Tue, 11 Feb 2020 at 19:08, Dik Takken wrote: > >> $($obj->Fot); >> However, wrapped inside $(), which only accepts >> functions and methods > > I don't think I meant that. I think it still should accept variables > as well, so it would still be ambiguous as to whether it referred to > the value of the property Fot of object $obj, or the method Fot on the > $obj class. In that case, the ambiguity issue remains. I was thinking about it as a construct for wrapping functions and methods into closures. Could you provide an example of how accepting variables would be useful? >> another possibility could be: closure(foo); > > That has the downside of exposing the implementation detail, that it's > implemented through closures, which would be a regrettable choice if > we ever decided to change the implementation details in the future. I don't think I understand. Creating a closure is something you do because of the specific semantics they have. The fact that it yields a closure is not a detail, it is the reason why I would use it... > And it also has the downside of looking like a function call, but > having different rules for what can be put inside it: > > function foo(); > closure(foo); // fine. > special_closure(foo); // syntax error, undefined constant foo. That is a downside indeed. Regards, Dik Takken