Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91443
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
To: internals@lists.php.net
References: <CA+kxMuTHbsYAXe+J+jrFz+ZeguacEyUxCUpFJE8jMee_5+u_5g@mail.gmail.com>
 <97.82.11730.D8C3FC65@pb1.pair.com> <56CF63D8.8020005@gmail.com>
 <C0.D2.55238.7D630D65@pb1.pair.com> <op.ydfu05klc9evq2@nikita-work-box>
Message-ID: <56D1F21E.404@gmail.com>
Date: Sat, 27 Feb 2016 18:59:42 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <op.ydfu05klc9evq2@nikita-work-box>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] Callable constructors
From: rowan.collins@gmail.com (Rowan Collins)

On 26/02/2016 11:47, Nikita Nefedov wrote:
>>> Then we could add to that a special case for constructors:
>>>
>>> - Callable::forConstructor(string $class_name)
>>>
>>
>> Oh, that's quite a clean solution, I like that. Heck, no need for 
>> Callable, we already have ->getClosure() in Reflection. A modified 
>> version of that for constructors could work 
>> (ReflectionClass::getConstructorClosure() ?).
>>
>> Thanks.
>
> Hey Andrea,
>
> This would still not solve Dan's problem though. Which is representing 
> `new Class` as a serializeable callable. 

There are lots of types of callable which can't be serialized already - 
anonymous functions, invokable objects, instance methods - so I'm still 
not convinced why this particular one is so important. Anything that can 
only take its callback as a string already rejects many things that are 
otherwise callable, so I'm not sure why having to reject a wrapped 
constructor is so much worse that it needs a new language concept.

Regards,

-- 
Rowan Collins
[IMSoP]