Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92461
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 157.56.111.140 as permitted sender)
To: Joe Watkins <pthreads@pthreads.org>
References: <CAL=_i_mzF5U4kb487igLrMPvnK5UUNP0W1FA+MYHWMjmypJ3Cg@mail.gmail.com>
 <BY2PR0201MB1784951F449DA564BF12AE3DBF6C0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAL=_i_mxPnzm4O7mpVFiGTtxnwDSUtpzM7f8Su=LwkHTa_agOw@mail.gmail.com>
 <CAL=_i_nJrbCaN4RC0HrV8t4a07ugwG-j373wocaidNfJtWAKNA@mail.gmail.com>
 <5716310B.4060104@zend.com>
 <CAL=_i_mriQQ_MKEw-zm_xfJh5tYb6_nzE6iLMXh0zYEuWG_OiQ@mail.gmail.com>
CC: PHP internals <internals@lists.php.net>
Message-ID: <57163CB0.70608@zend.com>
Date: Tue, 19 Apr 2016 17:12:00 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CAL=_i_mriQQ_MKEw-zm_xfJh5tYb6_nzE6iLMXh0zYEuWG_OiQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------080904040301060507060100"
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2016 14:12:13.4797 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1789
Subject: Re: [PHP-DEV] RFC: Functional Interfaces
From: dmitry@zend.com (Dmitry Stogov)

--------------080904040301060507060100
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit

For me, the proposal is too complex.
I prefer intuitive concepts, that I may use without rereading manual 
again and again.
For this one, I even can't imagine a natural (not over-designed) use case.
But this is my personal opinion, and I may be wrong :)

I'll review the code later.

Thanks. Dmitry.


On 04/19/2016 04:29 PM, Joe Watkins wrote:
> > What value?
>
> Yes, shorter, more concise (from the programmers perspective) syntax.
>
> Right now, if you do a lot of work with Closures, you have to verify 
> their interface, the value in having the engine do it for you seems 
> really obvious.
>
> But also ...
>
> > I thought the same might be implemented through anonymous classes.
>
> An anonymous class cannot be rebound, they are obviously not the same 
> thing.
>
> > I didn't take a deep look into the code.
>
> I'll wait until you have, I think :)
>
> Cheers
> Joe
>
> On Tue, Apr 19, 2016 at 2:22 PM, Dmitry Stogov <dmitry@zend.com 
> <mailto:dmitry@zend.com>> wrote:
>
>
>
>     On 04/19/2016 03:52 PM, Joe Watkins wrote:
>>     Oh, it's confusing text in the RFC, using the word "Interface"
>>     ... that's meant as a placeholder for InterfaceName.
>>
>>     Cheers
>>     Joe
>>
>>     On Tue, Apr 19, 2016 at 1:50 PM, Joe Watkins
>>     <pthreads@pthreads.org <mailto:pthreads@pthreads.org>> wrote:
>>
>>         Morning Dmitry,
>>
>>           In your example, they will do the same thing.
>>
>>           Anon classes don't have lexical scope, I have a patch for
>>         that, and an RFC, I'm just tidying it.
>>
>
>     OK. so this is not just a syntax sugar, but if you implement
>     lexical scope for anonymous classes it's going to be sugar. Right?
>     May be it's better to start from classes first?
>
>>
>>           Even when anon classes do have lexical scope, there is
>>         value in being able to implement these kinds of interfaces
>>         using only a function.
>>
>
>     What value? just shorter syntax? or anything else?
>
>>
>>           The changes to the vm are restricted to a few lines, that's
>>         not seriously a problem, is it !?
>>
>
>     I hope no. I didn't understand all details of proposal and I
>     didn't take a deep look into the code.
>
>>
>>           I don't see where I extend closure with an interface ...
>>
>
>     I meant new field zend_execute_data *interface in zend_closure
>     structure.
>     I thought the same might be implemented through anonymous classes.
>
>     Thanks. Dmitry.
>
>
>>
>>           > zend_do_inheritance_ex(type, zend_ce_closure, 1);
>>           >     zend_class_implements(type, 1, interface);
>>
>>         Cheers
>>         Joe
>>
>>         On Tue, Apr 19, 2016 at 1:01 PM, Dmitry Stogov
>>         <dmitry@zend.com <mailto:dmitry@zend.com>> wrote:
>>
>>             <?php
>>             interface IFoo {
>>                 public function method() : int;
>>             }
>>
>>             $cb1 = function () implements IFoo : int {
>>                 return 42;
>>             };
>>
>>             $cb2 = new class implements IFoo {
>>               function method() : int {
>>                 return 42;
>>              }
>>             };
>>             ?>
>>
>>             Are $cb1 and $cb2 going to be the same (do the same)?
>>             Is this just a new syntax sugar, or a really new feature?
>>
>>             According to implementation, I think, you shouldn't
>>             extend "zend_closure" with "interface".
>>             If this is a sugar, lets implement it as a sugar (without
>>             VM changes).
>>
>>             But may be I didn't understand the idea at all :)
>>
>>             Thanks. Dmitry.
>>
>>
>>             ________________________________________
>>             From: Joe Watkins <pthreads@pthreads.org
>>             <mailto:pthreads@pthreads.org>>
>>             Sent: Monday, April 18, 2016 13:22
>>             To: PHP internals
>>             Subject: [PHP-DEV] RFC: Functional Interfaces
>>
>>             Morning Internals,
>>
>>                 Please review the following RFC:
>>
>>             https://wiki.php.net/rfc/functional-interfaces
>>
>>                 An implementation is provided, and is testable on 3v4l.
>>
>>                 Review of the implementation from those of you that
>>             do that would be
>>             good :)
>>
>>             Cheers
>>             Joe
>>
>>
>>
>
>


--------------080904040301060507060100--