Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39609 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93611 invoked from network); 4 Aug 2008 08:54:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Aug 2008 08:54:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=helly@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=helly@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender) X-PHP-List-Original-Sender: helly@php.net X-Host-Fingerprint: 85.214.94.56 aixcept.net Linux 2.6 Received: from [85.214.94.56] ([85.214.94.56:52798] helo=h1149922.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 79/39-46562-0C3C6984 for ; Mon, 04 Aug 2008 04:54:24 -0400 Received: from MBOERGER-ZRH.corp.google.com (176-81.106-92.cust.bluewin.ch [92.106.81.176]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by h1149922.serverkompetenz.net (Postfix) with ESMTP id 2A69711EF83; Mon, 4 Aug 2008 10:54:21 +0200 (CEST) Date: Mon, 4 Aug 2008 10:51:31 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <1263891092.20080804105131@marcus-boerger.de> To: Stanislav Malyshev CC: Etienne Kneuss , PHP Internals List In-Reply-To: <48968E73.405@zend.com> References: <48968E73.405@zend.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Re: __invoke concerns From: helly@php.net (Marcus Boerger) Hello Stanislav, Monday, August 4, 2008, 7:06:59 AM, you wrote: > Hi! >> 1) With the interface, the prototype is fixed. > That definitely would not work. Interface could leave __invoke > undefined, though then it'd be more of documentation/attribute purpose > than enforcing having __invoke. But it can be workable. We have this for Traversable and because that one has no functions but rather is an internal and external tag it cannot be implemented by user classes directly. Instead the user must implement Iterator(Aggregate). In this case we probably do not want Invokable and InvokableReference though and simply combine with the magic function name. >> However, I'd still like to make closures more flexible and >> internals-friendly by implementing zend_get_closure as a handler. > Hmm... it may work, at least at the first glance I don't see any trouble > with it. Best regards, Marcus