Morgan L. Owens wrote:
I suppose if you're lucky the consumer doesn't need to remember any state
between one notification and the next, and it can treat every dataum like it's
the first. But that is hardly the general case.
Actually 75% of my 'producers' are simply reading the next line from a
Morgan L. Owens wrote:
I accept your point about not caring about how the data was created, but
on the other side, if the data creation is handling a lot more data than
the consumer needs there is an amount of processing time that is wasted.
The quick way of doing something does not equate to the
On 2012-08-23 00:10, Lester Caine wrote:
Then the next example is an 'iterator' ... which you are right ... I do
not appreciate either, because they require an insane amount of overhead
for what would be easy if the first example had been done right! I did
try them, in the past, but the overhead
On 2012-08-23 02:03, Lester Caine wrote:
I accept your point about not caring about how the data was created, but
on the other side, if the data creation is handling a lot more data than
the consumer needs there is an amount of processing time that is wasted.
The quick way of doing something doe
Nikita Popov wrote:
But I think I understood your main problem with generators now.
Generators are very useful for the creation of reusable and pluggable
components. You don't seem particularly fond of that kind of
programming and prefer hardcoded and tightly coupled implementations.
In that case
Ferenc Kovacs wrote:
So now you understand how the proposed Generator implementation works?
If you think that Iterators require a bunch of boilerplate code, I can
understand that, and that was one of the motivations behind the Generators rfc I
guess.
If you think that using Iterators (hence rever
On Wed, Aug 22, 2012 at 2:10 PM, Lester Caine wrote:
> Ferenc Kovacs wrote:
>>
>> I can't really follow your sql example, but let's try this another way:
>> You understand how Iterators work, right?
>> (http://php.net/manual/en/language.oop5.iterations.php
>>
>> http://www.php.net/manual/en/class.
>
>
> I've just gone back over the rfc and I probably understand now why I was
> getting confused. Actually it really does irritate that the first 'example'
> on the page is simply the wrong way of doing it anyway. We should not be
> propagating bad code like that and using it as justification for
Ferenc Kovacs wrote:
I can't really follow your sql example, but let's try this another way:
You understand how Iterators work, right?
(http://php.net/manual/en/language.oop5.iterations.php
http://www.php.net/manual/en/class.iterator.php)
The proposed generator implementation works the same way f
On Wed, Aug 22, 2012 at 12:11 PM, Lester Caine wrote:
> Ferenc Kovacs wrote:
>
>> it doesn't make a difference, if you yield only once, and put that into a
>> loop,
>> or copy paste the yield line ten times.
>> yield always does the same thing, pass the execution to the caller.
>>
>
> I KNOW that
Ferenc Kovacs wrote:
it doesn't make a difference, if you yield only once, and put that into a loop,
or copy paste the yield line ten times.
yield always does the same thing, pass the execution to the caller.
I KNOW that I am sounding thick here but "you don't have to understand the
underlying
On Wed, Aug 22, 2012 at 10:21 AM, Lester Caine wrote:
> Morgan L. Owens wrote:
>
>> As I wrote in an earlier post:
>>
>> On 2012-08-09 15:30, Morgan L. Owens wrote:
>> > I for one am lazy, and would much prefer writing:
>> > > > function append_iterator($first, $second)
>> > {
>> >foreac
Morgan L. Owens wrote:
As I wrote in an earlier post:
On 2012-08-09 15:30, Morgan L. Owens wrote:
> I for one am lazy, and would much prefer writing:
> function append_iterator($first, $second)
> {
>foreach($first as $i)
>{
>yield $i;
>}
>foreach($second as $i)
Oh, yes...
On 2012-08-22 04:35, Lester Caine wrote:
and doesn't seem to
provide any outstanding advantages?
As I wrote in an earlier post:
On 2012-08-09 15:30, Morgan L. Owens wrote:
> I for one am lazy, and would much prefer writing:
> function append_iterator($first, $second)
> {
>f
On 2012-08-22 04:35, Lester Caine wrote:
John LeSueur wrote:
Again, the case you've cited is probably not a case where generators
give much
advantage. But anytime the logic to produce some data becomes more
complicated
(Imagine that you needed to skip some of the lines in the .csv file
based on
Dearest Lester,
I know you don't understand generators. You've posted multiple times
about it. And you know what? It's okay; you don't have to understand
them. I do understand generators and would LOVE to have them
available for some of the things I do in my line of work; that's
perfectly fine
John LeSueur wrote:
Again, the case you've cited is probably not a case where generators give much
advantage. But anytime the logic to produce some data becomes more complicated
(Imagine that you needed to skip some of the lines in the .csv file based on
some kind of filter), then being able to e
On Tue, Aug 21, 2012 at 12:31 AM, Lester Caine wrote:
> Morgan L. Owens wrote:
>
>> For the third one ... I'm still waiting for some clarification on how
>>> yield is SUPPOSED to work anyway? If you are using a 'generator' to
>>> return a sequence of data elements, then just what does happen betw
Morgan L. Owens wrote:
For the third one ... I'm still waiting for some clarification on how
yield is SUPPOSED to work anyway? If you are using a 'generator' to
return a sequence of data elements, then just what does happen between
each call to the generator ... DOES the generator get called for
On 2012-08-21 01:10, Lester Caine wrote:
For the third one ... I'm still waiting for some clarification on how
yield is SUPPOSED to work anyway? If you are using a 'generator' to
return a sequence of data elements, then just what does happen between
each call to the generator ... DOES the genera
On Mon, Aug 20, 2012 at 10:07 PM, Ángel González wrote:
> On 20/08/12 15:12, Nikita Popov wrote:
>>> You could not decorate it and rely instead on the presence of the yield
>>> keyword, but parsers will thank knowing about it from the start rather
>>> than realising at mid-parsing that the functio
I think this doesn't bring anything further to talk about how to
implement this in the parser.
After reading the thread again, I would like to say that
- either this should be implemented as currently defined
- or it is implemented with the generator-keyword. But then it isn't a
function anymore,
On 18/08/12 13:21, Derick Rethans wrote:
On Sat, 11 Aug 2012, Nikita Popov wrote:
Hi internals!
I think there already was a lot of discussion on the generators, so
it's time to move to the next step. I'd like to vote on the feature in
two weeks, so this the "announce[ment] on internals@, by th
On 20/08/12 15:12, Nikita Popov wrote:
>> You could not decorate it and rely instead on the presence of the yield
>> keyword, but parsers will thank knowing about it from the start rather
>> than realising at mid-parsing that the function is a completely
>> different beast.
> No, parsers don't care
On 20/08/12 19:46, Stas Malyshev wrote:
Hi!
What would *actually* make sense here are return value typehints. E.g.
one could have something like `public Iterator getIterator() { ... }`.
And again we're back to inventing syntax to do what documentation should
be doing.
For the large part, but
Hi!
> What would *actually* make sense here are return value typehints. E.g.
> one could have something like `public Iterator getIterator() { ... }`.
And again we're back to inventing syntax to do what documentation should
be doing.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www
Hi!
> generator function f() {
> echo "Hello World";
> }
even more interesting,
$a = generator function() {
echo "Hello World";
}
or even:
function foo() {
return generator function() {
echo "Hello World";
}
}
$a = foo();
--
Stanislav Malyshev, Softw
> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: 20 August 2012 14:12
> To: Ángel González
> Cc: Rasmus Lerdorf; Stas Malyshev; Derick Rethans; PHP internals
> Subject: Re: [PHP-DEV] [RFC] Generators
>
> On Mon, Aug 20, 2012 at
Rasmus Lerdorf:
> So how about something like this:
>
> generator function f() {
> echo "Hello World";
> }
>
> generator function f() {
> return 1;
> }
>
> generator function f($arg) {
> if(f!$arg) yield 1;
> else if($arg<0) return 1;
> else return;
> }
>
> What does the generator key
On Mon, Aug 20, 2012 at 3:48 PM, Rasmus Lerdorf wrote:
> On 08/20/2012 07:56 AM, Ángel González wrote:
> > On 20/08/12 02:01, Rasmus Lerdorf wrote:
> >> I would still like to understand what this generator keyword would
> >> actually do. I don't see how it would work. Would a function marked
> >>
On Mon, Aug 20, 2012 at 1:56 PM, Ángel González wrote:
> On 20/08/12 02:01, Rasmus Lerdorf wrote:
>> I would still like to understand what this generator keyword would
>> actually do. I don't see how it would work. Would a function marked
>> generator somehow not be allowed to return normally or t
Rasmus Lerdorf wrote:
So how about something like this:
generator function f() {
echo "Hello World";
}
generator function f() {
return 1;
}
generator function f($arg) {
if(f!$arg) yield 1;
else if($arg<0) return 1;
else return;
}
What does the generator keyword mean in each of
On 08/20/2012 07:56 AM, Ángel González wrote:
> On 20/08/12 02:01, Rasmus Lerdorf wrote:
>> I would still like to understand what this generator keyword would
>> actually do. I don't see how it would work. Would a function marked
>> generator somehow not be allowed to return normally or to finish a
On 20/08/12 02:01, Rasmus Lerdorf wrote:
> I would still like to understand what this generator keyword would
> actually do. I don't see how it would work. Would a function marked
> generator somehow not be allowed to return normally or to finish and not
> return anything? How could this be enforce
hi Rasmus!
On Mon, Aug 20, 2012 at 2:01 AM, Rasmus Lerdorf wrote:
> I would still like to understand what this generator keyword would
> actually do. I don't see how it would work. Would a function marked
> generator somehow not be allowed to return normally or to finish and not
> return anythin
> -Original Message-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: 20 August 2012 00:08
> To: Derick Rethans
> Cc: Nikita Popov; PHP internals
> Subject: Re: [PHP-DEV] [RFC] Generators
>
> Hi!
>
> > I am against this. This is even m
On 08/19/2012 07:07 PM, Stas Malyshev wrote:
> Hi!
>
>> I am against this. This is even more magic in PHP. Is it really that
>> difficult to have to mark the function with a different keyword, such as
>> "generator":
>
> You have a point here, but "public static final generator function
> foo()
Hi!
> I am against this. This is even more magic in PHP. Is it really that
> difficult to have to mark the function with a different keyword, such as
> "generator":
You have a point here, but "public static final generator function
foo()" sounds a bit long-winded to me... Also, we'd have then t
Nikita Popov wrote:
I don't understand this argument. Generator functions are transparent
to the user. You use a generator function just like you would use a
function that returns an array. From a user point of view it does not
matter whether getLinesFromFile() is just a function returning an
ar
On Sat, Aug 18, 2012 at 4:12 PM, wrote:
> Since this is yet another area where 'one does not have to use it if one
> does not want to' ... FLAGGING to the other users that a function is a
> 'special one' rather than just a normal function with a generator function
> seems to me just a necessity?
On 08/18/2012 10:12 AM, les...@lsces.co.uk wrote:
> Since this is yet another area where 'one does not have to use it if one
> does not want to' ... FLAGGING to the other users that a function is a
> 'special one' rather than just a normal function with a generator function
> seems to me just a nec
> On Sat, 11 Aug 2012, Nikita Popov wrote:
>
>> Hi internals!
>>
>> I think there already was a lot of discussion on the generators, so
>> it's time to move to the next step. I'd like to vote on the feature in
>> two weeks, so this the "announce[ment] on internals@, by the author,
>> with the inten
On Sat, Aug 18, 2012 at 2:21 PM, Derick Rethans wrote:
> I've some comments how that I've read the RFC:
>
>> Recognition of generator functions
>>
>> 1. Any function which contains a yield statement is automatically a
>> generator function.
>>
>> 2. The initial implementation required that generat
On Sat, 11 Aug 2012, Nikita Popov wrote:
> Hi internals!
>
> I think there already was a lot of discussion on the generators, so
> it's time to move to the next step. I'd like to vote on the feature in
> two weeks, so this the "announce[ment] on internals@, by the author,
> with the intention of
On Tue, Aug 14, 2012 at 7:59 PM, Aaron Holmes wrote:
> Thanks for clarifying. It makes sense now, considering foreach's behavior
> and the generators statefulness allowing what otherwise seems inconsistent.
> However, might it make sense to no-op instead of erroring? If generators
> allow rewind()
On 8/14/12 10:36 AM, Stas Malyshev wrote:
Hi!
That said, rewind() should behave consistently. I don't feel it makes
sense to have rewind() succeed at one point, and fail at another. It
would only cause confusion when not familiar with the behavior. Either
allow it, or don't. Not both.
It does,
Hi!
> That said, rewind() should behave consistently. I don't feel it makes
> sense to have rewind() succeed at one point, and fail at another. It
> would only cause confusion when not familiar with the behavior. Either
> allow it, or don't. Not both.
It does, since foreach uses rewind. So fir
On 8/13/12 9:09 AM, Nikita Popov wrote:
On Sun, Aug 12, 2012 at 10:08 PM, Brian Moon wrote:
Also, not allowing rewinding is unintuitive for something that is an
iterator in PHP. If I can foreach() it and I can call next() on it, I expect
to be able to reset() it as well. IMO, you would need to
gt; Gesendet: 18:09 Montag, 13.August 2012
> Betreff: Re: [PHP-DEV] [RFC] Generators
>
> On Sun, Aug 12, 2012 at 10:08 PM, Brian Moon wrote:
>> Also, not allowing rewinding is unintuitive for something that is an
>> iterator in PHP. If I can foreach() it and I can call next()
2012/8/13 Nikita Popov :
> * After first yield: Recoverable fatal error
>
> So this would allow you to call ->rewind() after creating the
> generator, but will throw an error if you try to do so later.
Hm. I think this looks like a workaround over conceptual problems.
The (in my eyes) "right" beh
2012/8/13 Anthony Ferrara :
> It's absolutely something that takes getting used to. But it's also quite
> intuitive once you think about it. You're not "returning" back to the
> parent scope (exiting your scope), you're "yielding" a value to the parent
> scope, expecting to continue on later (think
On Sun, Aug 12, 2012 at 10:08 PM, Brian Moon wrote:
> Also, not allowing rewinding is unintuitive for something that is an
> iterator in PHP. If I can foreach() it and I can call next() on it, I expect
> to be able to reset() it as well. IMO, you would need to issue a FATAL PHP
> error if that sim
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: 13 August 2012 03:49
> To: Brian Moon
> Cc: Nikita Popov; PHP internals
> Subject: Re: [PHP-DEV] [RFC] Generators
>
> Brian,
>
> On Sun, Aug 12, 2012 at 4:08 PM, Brian Mo
Brian,
On Sun, Aug 12, 2012 at 4:08 PM, Brian Moon wrote:
> Hi Nikita,
>
> I admit, I have ignored these threads as there was no RFC. So, some of
> this may have been covered.
>
There was an RFC in those posts... It was just being iterated over.
> Do you have a good example usage other than a
On Sun, Aug 12, 2012 at 8:25 PM, Brian Moon wrote:
>>> I don't consider this a very good example.
>>
>> That's fine. You are entitled to your opinion. However, you didn't
>> have to figure out the 106 lines of code that is the Post-Order
>> iterator. That was a NIGHTMARE and I'm still not 100% c
I don't consider this a very good example.
That's fine. You are entitled to your opinion. However, you didn't
have to figure out the 106 lines of code that is the Post-Order
iterator. That was a NIGHTMARE and I'm still not 100% confident that
it works as it is supposed to. The generator, on th
I guess to be completely honest, there would be a docblock above the
generator code as well. So 14 lines.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, Aug 12, 2012 at 5:56 PM, Brian Moon wrote:
> On 8/12/12 5:33 PM, Levi Morrison wrote:
>>
>> On Sun, Aug 12, 2012 at 2:08 PM, Brian Moon wrote:
>>>
>>> Do you have a good example usage other than a file? I don't find
>>> fopen/fgets/fclose all that complicated. What are the other valid use
On 8/12/12 5:33 PM, Levi Morrison wrote:
On Sun, Aug 12, 2012 at 2:08 PM, Brian Moon wrote:
Do you have a good example usage other than a file? I don't find
fopen/fgets/fclose all that complicated. What are the other valid use cases for
such a thing?
One fabulous use case is creating an ite
On 13 באוג 2012, at 01:33, Levi Morrison wrote:
> On Sun, Aug 12, 2012 at 2:08 PM, Brian Moon wrote:
>> Do you have a good example usage other than a file? I don't find
>> fopen/fgets/fclose all that complicated. What are the other valid use cases
>> for such a thing?
>
> One fabulous use ca
On Sun, Aug 12, 2012 at 2:08 PM, Brian Moon wrote:
> Do you have a good example usage other than a file? I don't find
> fopen/fgets/fclose all that complicated. What are the other valid use cases
> for such a thing?
One fabulous use case is creating an iterator for a Binary Search
Tree. A post
Hi Nikita,
I admit, I have ignored these threads as there was no RFC. So, some of
this may have been covered.
Do you have a good example usage other than a file? I don't find
fopen/fgets/fclose all that complicated. What are the other valid use
cases for such a thing?
Also, not allowing re
Hi internals!
I think there already was a lot of discussion on the generators, so
it's time to move to the next step. I'd like to vote on the feature in
two weeks, so this the "announce[ment] on internals@, by the author,
with the intention of voting on it".
https://wiki.php.net/rfc/generator
63 matches
Mail list logo
