Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39621
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.46.28 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=ml0NP55MmP6ozmJSOSBfwCFf3jLAsFtGmT/XBvbmyFLygeUzxZPeUcsfO9MOFlwCJ6
         pQaDGA74TOPi5y/7BL58EJ4NIuhI/THQvdr/btig9A0qsWEQYlIqkRK0BghcyZhTOEkg
         xm44o6Sar4YT+VTdM/fOuqqb8p11rBkjPrXp8=
Message-ID: <e666c3890808040351m17c8e648me334c3c1665b2d2a@mail.gmail.com>
Date: Mon, 4 Aug 2008 12:51:50 +0200
Sender: ekneuss@gmail.com
To: "Stanislav Malyshev" <stas@zend.com>
Cc: "PHP Internals List" <internals@lists.php.net>
In-Reply-To: <48968C57.6070502@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e666c3890808021036p58de549as422bec8471b7a992@mail.gmail.com>
	 <48968C57.6070502@zend.com>
Subject: Re: [PHP-DEV] __invoke concerns
From: colder@php.net ("Etienne Kneuss")

Hello,

Hello,

On Mon, Aug 4, 2008 at 6:57 AM, Stanislav Malyshev <stas@zend.com> wrote:
> Hi!
>
>> 1) I don't believe that having it thrown as another of those magic
>> method is a good idea. Rather, I'd like to have it represented by an
>> interface: Invokable. That way, type hints/checks can be done in user
>> land in a sane matter:
>
> We can have Invokable and even have Closure implement it, if there's need, I
> see no problem with it.
> However, I'm not sure we should *require* interface membership for __invoke
> to work - I do not see any added value in this.

I'm not sure I understand what you mean? Either the interface covers
__invoke and "$obj instanceof Invokable" is a safe check to know if we
can $obj();, or it doesn't and we know nothing.

>
>> 2) Do we really want __invoke's argument to be mapped to caller
>> arguments. Providing an array of arguments, ala __call(Static) sounds
>> more consistent.
>
> More "consistent" with what? __call is different from __invoke - __call is
> global interceptor (takes any function), __invoke is not. And you can easily
> convert it to array with function_get_args().

I agree, it's a feature that works "similarly" as __construct, and we
don't have __construct($args);
Additionally, it would require more work to distinguish:

$a = function($b,$c) { ... };
$a(1,2);

from

class A  {
   public function __invoke($args) {

   }
}
$a = new A;
$a(1,2);
as we certainly don't want function($args){}.

In overall, there is no need to discuss that Interface much, as it
causes more problems than it solves.

But please check out the get_closure handler.

>
>> 3) Do we really want to allow both static and non-static versions of
>> __invoke ?
>> class A { public static function __invoke($args) { .. }} $a = new A;
>> $a(); being a static call to __invoke doesn't make much sense to me.
>
> I don't see how static __invoke may be useful. Anyone has a use case?
> --
> Stanislav Malyshev, Zend Software Architect
> stas@zend.com   http://www.zend.com/
> (408)253-8829   MSN: stas@zend.com
>
>



-- 
Etienne Kneuss
http://www.colder.ch

Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal