hakre wrote:
>> Also, currently yield looks very similar to return and I think this
>> is a nice thing as it is similar semantically. yield($foo) would
>> give it different semantics, imho.
>
> I love this point a lot. Return is very common and yield is some
> kind of return.
>
I agree also: yiel
Mike Ford wrote:
>
> The signposting needn't even be as in-your-face as a generator
> keyword (either instead of or in addition to function): I could get
> behind a variation such as:
>
> function f($x, $y) yields { ... yield $z; ... }
>
> Or even (stretching a bit to re-use an existing keyword!):
> Also, currently yield looks very similar to return and I think this is
> a nice thing as it is similar semantically. yield($foo) would give it
> different semantics, imho.
I love this point a lot. Return is very common and yield is some kind of return.
--
PHP Internals - PHP Runtime Developm
On Thu, Aug 9, 2012 at 5:59 PM, Andrew Faulds wrote:
> yield(), so far as the programmer is concerned, might as well be a function.
> It isn't, strictly speaking, but like other function calls, it suspends
> execution of the function until the called function completes.
>
> So I don't think this i
On 09/08/12 16:58, Nikita Popov wrote:
On Wed, Aug 8, 2012 at 10:55 PM, Andrew Faulds wrote:
Hmm. This is just a quick thought:
Considering the yield syntax will vary about needing () round it, why not
make it a "fake" function (language construct).
This way it's consistent: yield(), yield($v
On Wed, Aug 8, 2012 at 10:55 PM, Andrew Faulds wrote:
> Hmm. This is just a quick thought:
>
> Considering the yield syntax will vary about needing () round it, why not
> make it a "fake" function (language construct).
>
> This way it's consistent: yield(), yield($v), yield($k => $v), $a = yield()
On 2012-08-09 08:42, Nikita Popov wrote:
Without parenthesis their behavior in array definitions and nested
yields is ambigous:
array(yield $key => $value)
// can be either
array((yield $key) => $value)
// or
array((yield $key => $value))
yield yield $key => $value;
// can be either
yield (yie
On 08/08/12 21:43, Stas Malyshev wrote:
Hi!
https://wiki.php.net/rfc/generators#yield_keyword
https://wiki.php.net/rfc/generators#sending_values
I'm not sure $data = (yield $value) makes a lot of sense. Why we have
two variables here? Why it is only operator in the language that
requires pare
Hi!
> https://wiki.php.net/rfc/generators#yield_keyword
> https://wiki.php.net/rfc/generators#sending_values
I'm not sure $data = (yield $value) makes a lot of sense. Why we have
two variables here? Why it is only operator in the language that
requires parentheses around? All these complex paren
On Wed, Aug 8, 2012 at 10:27 PM, Andrew Faulds wrote:
> Hi Nikita,
>
> I notice you require brackets round yield $k => $v and yield $v. Is this the
> formal syntax, i.e. '(' T_YIELD var => var ')'? If so it makes sense in a
> way, but it feels a little hackish. Does yield $v cause some sort of par
On 08/08/12 21:14, Nikita Popov wrote:
On Fri, Jul 27, 2012 at 8:09 PM, Nikita Popov wrote:
5. Are multiple yields allowed? I.e. the rfc mentions something like
yield yield $a - what that would mean? I'd allow yield only be applied
to variable expression (lval) because double yield doesn't make
On Fri, Jul 27, 2012 at 8:09 PM, Nikita Popov wrote:
>> 5. Are multiple yields allowed? I.e. the rfc mentions something like
>> yield yield $a - what that would mean? I'd allow yield only be applied
>> to variable expression (lval) because double yield doesn't make sense to
>> me, but maybe I miss
On Thu, Jul 26, 2012 at 2:20 AM, Stas Malyshev wrote:
> Hi!
>
>> The implementation is outlined in the RFC-stub here:
>> https://wiki.php.net/rfc/generators
>>
>> Before going any further I'd like to get some comments about what you
>> think of adding generator support to PHP.
>
> Some notes on th
2012/7/26 Bernhard Schussek :
[about doc-blocks]
Fact: Doc blocks are not forced by the language.
Fact: For an IDE an own keyword will help the parser to distinct
faster/easier between "normal" functions and a generator.
Experience: IDEs will have their problems implementing this - think at
first
I too don't think that a new keyword is necessary for this case. Let's
not forget that it is a common practice to document functions with doc
blocks, which further helps understanding what it does.
/**
* @return Generator
* @yield string
*/
function generate() {
...
yield $foo;
...
}
Che
Hi!
> The implementation is outlined in the RFC-stub here:
> https://wiki.php.net/rfc/generators
>
> Before going any further I'd like to get some comments about what you
> think of adding generator support to PHP.
Some notes on the RFC:
1. I think we should support rewind() by just creating a n
2012/7/26 Yahav Gindi Bar :
> "yielder" sounds quite weird don't you think (but my native language is not
> English too.. so don't blame me at english stupid conclusions!)
>
>> Fact: generator is not a good keyword, because too common.
> I can't see the connection... people relate the generator ke
On 26 ביול 2012, at 01:22, Alex Aulbach wrote:
> 2012/7/25 Nikita Popov :
>> particular with namespaced code). So if you have some kind of
>> Code\Generator class, you're screwed.
>> Keywords don't grow on trees, you know ;)
>
> Hm. Ok, thats a problem.
> Oh, man, do I really have to find a goo
Am Mi, 13.06.2012, 00:06 schrieb Nikita Popov:
> That's how it is currently implemented. The generator backs up the
> current execution context (execute_data, CVs, Ts), pushed stack
> arguments and several executor globals. When the generator is resumed
> everything is restored and it continues to
On Tue, Jun 12, 2012 at 11:07 PM, Ángel González wrote:
> On 11/06/12 23:12, Tom Boutell wrote:
>> Can you really use setjmp and longjmp in that way safely? I thought it
>> was only safe to longjmp "back," not "forward" - you can use them to
>> fake exception support but that's it because you'll s
On 11/06/12 23:12, Tom Boutell wrote:
> Can you really use setjmp and longjmp in that way safely? I thought it
> was only safe to longjmp "back," not "forward" - you can use them to
> fake exception support but that's it because you'll smash the stack
> otherwise. Something like that...
My first re
I don't understand why you need to introduce two new keywords into the
language - * and yield. Could you not solve it like follows?
// Generator implements Iterable
class AllEvenNumbers extends Generator {
private $i;
public __construct() { $this->i = 0; }
function generate() {
return
Hi,
as i've mentioned, that's up to implementation, for more infos please pay
attention to
http://en.wikipedia.org/wiki/Coroutine#Implementations_for_C
Well, the libtask mentioned there isn't thread safe (but could be made).
Especially have earned some attention
http://msdn.microsoft.com/en-us
Can you really use setjmp and longjmp in that way safely? I thought it
was only safe to longjmp "back," not "forward" - you can use them to
fake exception support but that's it because you'll smash the stack
otherwise. Something like that...
OK, I'm thinking of this:
"Similarly, C99 does not requ
Hi,
it'd be really cool if the implementation would do the "real" context
switch in c, which would be the true basis for spl_coroutine. The current
implementation seems not to do that.
Context switch in c would be comparable with threads. In fact coroutines
would be a comensation for lacking thre
Hi Nikita,
On 08/06/12 13:16, Nikita Popov wrote:
On Wed, Jun 6, 2012 at 12:20 PM, Ivan Enderlin @ Hoa
wrote:
In addition to Gustavo's remarks, I wonder how the GC would collect a
Generator object that is not use anymore (especially with a referenced
yield). Does it fit to the current CG strat
On Fri, 8 Jun 2012 13:24:49 +0200, Nikita Popov wrote:
Are you planning on any internal API for functions to implement
generators
(though I really haven't thought how that would work)?
I don't think that this is possible. Generators require that the
execution context is suspended in some way an
On Thu, Jun 7, 2012 at 10:46 AM, Gustavo Lopes wrote:
> I mean how do you deal with "return $foo" in the body of the generator? Does
> it work like a final yield? Is the return value ignored?
Currently there will be a fatal error if return statements (with
values) are used in the generator. In the
On Wed, Jun 6, 2012 at 12:20 PM, Ivan Enderlin @ Hoa
wrote:
> In addition to Gustavo's remarks, I wonder how the GC would collect a
> Generator object that is not use anymore (especially with a referenced
> yield). Does it fit to the current CG strategy or do we need an extra
> strategy? I would n
(Sorry, I pressed something that sent the message prematurely)
On Thu, 7 Jun 2012 01:10:52 +0200, Nikita Popov wrote:
current() and key() should return false when !valid()
Are you sure about that? The Iterator::current() docs don't specify
anything, but the Iterator::key() docs say that it sh
On Thu, 7 Jun 2012 01:10:52 +0200, Nikita Popov wrote:
current() and key() should return false when !valid()
Are you sure about that? The Iterator::current() docs don't specify
anything, but the Iterator::key() docs say that it should return NULL
on failure. Checking on the first spl class tha
Nikita,
> I don't know whether that behavior is of any use, so I'll gladly
> change the behavior to throwing an exception if that's more desirable.
You can't throw an exception from rewind, since it's called before
foreach(). So it wouldn't be iterable then.
I think the noop on rewind is valid
On Wed, Jun 6, 2012 at 10:55 AM, Gustavo Lopes wrote:
> On Tue, 5 Jun 2012 19:35:14 +0200, Nikita Popov wrote:
>>
>>
>> Before going any further I'd like to get some comments about what you
>> think of adding generator support to PHP.
>>
>
> I approve.
>
> A few comments on the current RFC:
>
> *
On Wed, Jun 6, 2012 at 10:09 AM, Nikita Popov wrote:
> On Tue, Jun 5, 2012 at 8:32 PM, Kris Craig wrote:
> > Some observations and questions:
> >
> > In the RFC, the top example claims to make use of the file() function,
> but
> > in fact does not. Did you mean fopen()? Or did you mean that thi
On Wed, Jun 6, 2012 at 4:15 AM, Laruence wrote:
> Hi Nikita:
>
> the most important part to me is how did you implemented `yield`
> keyword, is there a whole patch file I can look into?
>
> what will happen if you use a `yield` in a normal function?
>
> actually, I tried to implemented
On Tue, Jun 5, 2012 at 8:52 PM, Benjamin Eberlei wrote:
> This is really awesome. Some remarks:
>
> 1. The * looks a bit hidden. How about reusing the yield keyword? "function
> yield getLines()"
I mainly chose the * modifier because this is how JavaScript
(ECMAScript Harmony) does it. It also see
On Tue, Jun 5, 2012 at 8:32 PM, Kris Craig wrote:
> Some observations and questions:
>
> In the RFC, the top example claims to make use of the file() function, but
> in fact does not. Did you mean fopen()? Or did you mean that this to be an
> example of someone writing their own file() function
On 06/06/12 12:20, Ivan Enderlin @ Hoa wrote:
> On 05/06/12 19:35, Nikita Popov wrote:
>> Hi internals!
> Hi Nikita,
>
>> Before going any further I'd like to get some comments about what you
>> think of adding generator support to PHP.
> I have always hoped to see the “yield” keywork introduced in
Hello Ivan,
Moreover, I wonder how a “recursive yield” would act (something like
> “public function *f ( … ) { … yield $this->f(…); … }”). It is possible? Is
> it anticipated?
>
According to the RFC, your syntax will yield an entire generator and not
its intividual values. Please consider this
On 05/06/12 19:35, Nikita Popov wrote:
Hi internals!
Hi Nikita,
Before going any further I'd like to get some comments about what you
think of adding generator support to PHP.
I have always hoped to see the “yield” keywork introduced in PHP. I even
suggested that in this mailing-list at least
hi Rasmus, Sara,
Adding Sara to the loop as she is around and may miss that thread. We
also tried to convince her to contribute that back to core :)
On Wed, Jun 6, 2012 at 10:11 AM, Rasmus Lerdorf wrote:
> On 06/06/2012 04:42 AM, Laruence wrote:
>> On Wed, Jun 6, 2012 at 10:27 AM, Laruence wrot
On Tue, 5 Jun 2012 19:35:14 +0200, Nikita Popov wrote:
Before going any further I'd like to get some comments about what you
think of adding generator support to PHP.
I approve.
A few comments on the current RFC:
* The RFC is too vague.
* You're violating the contract of Iterator left and r
On 06/06/2012 04:42 AM, Laruence wrote:
> On Wed, Jun 6, 2012 at 10:27 AM, Laruence wrote:
>> On Wed, Jun 6, 2012 at 10:15 AM, Laruence wrote:
>>> Hi Nikita:
>>>
>>>the most important part to me is how did you implemented `yield`
>>> keyword, is there a whole patch file I can look into?
>>
On Wed, Jun 6, 2012 at 10:27 AM, Laruence wrote:
> On Wed, Jun 6, 2012 at 10:15 AM, Laruence wrote:
>> Hi Nikita:
>>
>> the most important part to me is how did you implemented `yield`
>> keyword, is there a whole patch file I can look into?
> Nervermind, I will check the branch out later
>
On Wed, Jun 6, 2012 at 10:15 AM, Laruence wrote:
> Hi Nikita:
>
> the most important part to me is how did you implemented `yield`
> keyword, is there a whole patch file I can look into?
Nervermind, I will check the branch out later
thanks
>
> what will happen if you use a `yield` in a n
Hi Nikita:
the most important part to me is how did you implemented `yield`
keyword, is there a whole patch file I can look into?
what will happen if you use a `yield` in a normal function?
actually, I tried to implemented coroutine, but since I could not
find a way to make zend_e
On Tue, Jun 5, 2012 at 10:35 AM, Nikita Popov wrote:
> Hi internals!
>
> In the last few days I've created a proof of concept implementation
> for generators in PHP. It's not yet complete, but the basic
> functionality is there:
> https://github.com/nikic/php-src/tree/addGeneratorsSupport
>
> The
47 matches
Mail list logo
