Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84233 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10205 invoked from network); 3 Mar 2015 12:52:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Mar 2015 12:52:25 -0000 Authentication-Results: pb1.pair.com smtp.mail=me@kelunik.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=me@kelunik.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.162 cause and error) X-PHP-List-Original-Sender: me@kelunik.com X-Host-Fingerprint: 81.169.146.162 mo4-p00-ob.smtp.rzone.de Received: from [81.169.146.162] ([81.169.146.162:47458] helo=mo4-p00-ob.smtp.rzone.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D7/47-03783-78EA5F45 for ; Tue, 03 Mar 2015 07:52:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1425387141; l=10825; s=domk; d=kelunik.com; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version; bh=ZHbXL2mc2zE9jTU+n+wwK0r0X/YdctgEZ73JtPb2Gfk=; b=LUtMaLLUkevS1VwPwS8W4KrigD/kPMMi4oX2JC2LZCoq7gT6hy548EisZg0pL45ERLO EpPeApMhwcEoE62lHO404cRg2CqazaTCSefolZveISz4223wSM0NM+H7owZx5ZsbTcBHo 5zZIuhVkdi8ZUSb0QCzfLYFCige7f8JchFk= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLGvomb4bl9EfHtO3c6 X-RZG-CLASS-ID: mo00 Received: from mail-wg0-f44.google.com ([74.125.82.44]) by smtp.strato.de (RZmta 37.3 AUTH) with ESMTPSA id z07a2cr23CqLHTG (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) for ; Tue, 3 Mar 2015 13:52:21 +0100 (CET) Received: by wgha1 with SMTP id a1so39781510wgh.12 for ; Tue, 03 Mar 2015 04:52:21 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.236.200 with SMTP id uw8mr67322593wjc.10.1425387141207; Tue, 03 Mar 2015 04:52:21 -0800 (PST) Received: by 10.27.77.131 with HTTP; Tue, 3 Mar 2015 04:52:21 -0800 (PST) In-Reply-To: <54F5A8C4.8070508@gmail.com> References: <54F59C45.7080704@gmail.com> <54F5A8C4.8070508@gmail.com> Date: Tue, 3 Mar 2015 13:52:21 +0100 Message-ID: To: Rowan Collins Cc: Bob Weinand , Daniel Lowrey , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=089e01493f60381b2a051061cef4 Subject: Re: [PHP-DEV] [RFC Discuss] Generator Delegation From: me@kelunik.com (Niklas Keller) --089e01493f60381b2a051061cef4 Content-Type: text/plain; charset=UTF-8 2015-03-03 13:27 GMT+01:00 Rowan Collins : > Bob Weinand wrote on 03/03/2015 12:08: > > Am 03.03.2015 um 12:34 schrieb Rowan Collins : >>> >>> Niklas Keller wrote on 03/03/2015 10:55: >>> >>>> Gr, top-posting... >>>> >>>> >>>> Sorry, was on mobile. ;-) >>>> >>>> However, since the existence of the word "yield" is the only thing >>>> that >>>> marks a coroutine now, how about using a variant of that for the >>>> final >>>> value, e.g. "yield final $foo"? >>>> >>>> >>>> What's the final value? The last "yield"ed value or a return? >>>> >>> "yield final" would mark the final result of the coroutine, as opposed >>> to the intermediate values passed out with a normal "yield". >>> >>> >>> Just to give you some real world example: >>>> If you're using "return", it would look like that: >>>> >>>> public function getSession ($sessionId) { >>>> $result = yield $this->redis->get("session.{$sessionId}")); // >>>> We're waiting here until redis responded. >>>> return json_decode($result); >>>> } >>>> >>> My suggestion is simply to change the keyword: >>> >>> public function getSession ($sessionId) { >>> $result = yield $this->redis->get("session.{$sessionId}")); // >>> We're waiting here until redis responded. >>> yield final json_decode($result); >>> } >>> >>> >>> The reasoning being that when you run getSession(42), it *doesn't* >>> return the result of json_decode(), it returns a pointer to the coroutine's >>> state, which you can resume later. >>> >>> Actually, I don't think that example makes sense, because JSON gets sent >>> out at the first yield, and then sent back in, so the caller would look >>> something like this: >>> >>> $foo = getSession(42); >>> $json_data = $foo->current(); >>> $foo->send($json_data); >>> $decoded = $foo->getReturn(); >>> >>> But never mind, I think we both get the idea. >>> >>> I understand the desire for a "final result", but I don't like reusing >>> the word "return", because it's never "returned" as the result of running >>> the function, it's just made available through some specific method/syntax. >>> >>> Regards, >>> -- >>> Rowan Collins >>> [IMSoP] >>> >> Hey, >> >> We currently already have "return;" (without value) as allowed syntax to >> terminate Generator execution. Thus, the logical consequence is just adding >> a value to that return. >> > > Hm, I didn't realise that. I suppose it makes sense that you'd want a way > to do that, but it does make it very hard to see if something's going to > behave as a function or a coroutine if they use the same keywords to mean > different things. > > When we want to *return*, it should be also a real *return". Yes, it is >> just accessible through special syntax (or a method), but it's still >> *return*ing into the calling frame. >> > > Well, so is "yield" - it just leaves the Generator in a state that can be > resumed, whereas "return"/"yield final" leaves it in a final, non-resumable > state. > > Why should the word "return" be unique to methods or functions? >> > > It just doesn't feel like the same thing as a return value to me, for the > same reason a generator doesn't feel like the same thing as a function. In > "function foo() { return 42; }", "return" means "this is what you'll get > when you run foo()"; in "function foo() { return 42; yield; }", what you > get when you run foo() is a pointer to the resumable state, and return > means "this is what you'll get if you ask the generator/coroutine instance > you get by running foo() for its final result". > > > Regards, > -- > Rowan Collins > [IMSoP] > It's still different from "return". You said, it "mark[s] the final result", so I'd expect that finally yielded value would be at the iterator, but it's not. It's separate. How would you call the method then, that makes that "yield final" value available? Regards, Niklas --089e01493f60381b2a051061cef4--