[PHP-DEV] Generators in PHP

On Tue, Jun 5, 2012 at 7:35 PM, Nikita Popov <[email protected]> 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 implementation is outlined in the RFC-stub here:
> https://wiki.php.net/rfc/generators

A small progress update on this:

* There now is support for yield by reference
* Generators are now automatically detected by the presence of "yield"
instead of requiring the "*" modifier.

The main open point I still have is whether or not generators should
have a throw() method (á la Python). I couldn't yet find a convincing
use case for it, so I'm considering to just leave it out.

If there is any further feedback on the proposal, I'd love to hear it :)

Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

> -----Original Message-----
> From: Nikita Popov [mailto:[email protected]]
> Sent: 20 July 2012 21:46
> To: Nikita Popov
> Cc: PHP internals
> Subject: [PHP-DEV] Re: Generators in PHP
>
> On Tue, Jun 5, 2012 at 7:35 PM, Nikita Popov
> <[email protected]> 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 implementation is outlined in the RFC-stub here:
> > https://wiki.php.net/rfc/generators
>
> A small progress update on this:
>
> * There now is support for yield by reference

Can't yield a reference to an array item directly.

Eg.

function &map(array &$row)
{
yield $row[0];
}

Also seems to be a problem with iterating

foreach(map($row) as &$value)

cannot be done without a fatal error

$i = map($row);
foreach($i as &$value)

however works.

> * Generators are now automatically detected by the presence of
"yield"
> instead of requiring the "*" modifier.
>
> The main open point I still have is whether or not generators
> should have a throw() method (á la Python). I couldn't yet
> find a convincing use case for it, so I'm considering to just
> leave it out.
>

Seems relatively easy to trigger a infinite loop atm.

Typo'd a SQL table name which caused an exception within PDO inside a
generator function, which then caused an infinite loop.


> If there is any further feedback on the proposal, I'd love to
> hear it :)
>
> Nikita
>
> --
> PHP Internals - PHP Runtime Development Mailing List To
> unsubscribe, visit: http://www.php.net/unsub.php
>


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, Jul 21, 2012 at 6:31 PM, Jared Williams
<[email protected]> wrote:
> Can't yield a reference to an array item directly.
>
> Eg.
>
> function &map(array &$row)
> {
> yield $row[0];
> }

Thanks, this is fixed now.

> Also seems to be a problem with iterating
>
> foreach(map($row) as &$value)
>
> cannot be done without a fatal error
>
> $i = map($row);
> foreach($i as &$value)
>
> however works.

This was an old foreach restriction that never really made sense and
makes even less sense once generators are in. So I dropped it. Now
everything can be iterated by-reference.

> Seems relatively easy to trigger a infinite loop atm.
>
> Typo'd a SQL table name which caused an exception within PDO inside a
> generator function, which then caused an infinite loop.

I forgot to rethrow the exception in the foreach scope. Should be fixed now.

Thanks for your feedback!

Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/20 Nikita Popov <[email protected]>:
> On Tue, Jun 5, 2012 at 7:35 PM, Nikita Popov <[email protected]> wrote:
>> Hi internals!
>> The implementation is outlined in the RFC-stub here:
>> https://wiki.php.net/rfc/generators
>
> A small progress update on this:

> * Generators are now automatically detected by the presence of "yield"
> instead of requiring the "*" modifier.

My first thought was how could someone reading the code see, that it
is a generator?

I mean: The "yield" can be between 50 lines of code. How could someone
see that? That a machine can do this is out of question, but humans
can't see that. Why is this important? Because when I see such code as
in the RFC and overlook the "yield" I would think "WTF", how could the
code work like this?

Why would someone not see this? Assume that the code was written and
is now quite old. The original developer is gone. A new one sits on
his place and now the customer says "hey, there is a bug anywhere".
The developer begins to search for it, and has no clue, how he can
reproduce it. Maybe he finds a part and he thinks now "Whoa, WTF" and
begins to debug that. After a while he will of course find "Oh, it's a
generator... just forgotten, that PHP can have that and the 'yield' is
so small in the middle of the function, nobody will see that..." But
he has spend some time to find that out.

That's what I think will happen. I think "yield" makes it more
difficult to maintain unknown code.

I think "yield" alone is too less. I think the function should be
explicitly marked as generator function.

Stupid Suggestions:
----------------------------

generator function gen()
{
yield 1;
}

generator gen()
{
yield 1;
}

function generator gen()
{
yield 1;
}

Hm... not really satisfied with that. For me this is a little bit
unlogical, that just a simple function can return an object.

So, how about implementing as a class? I mean: If it is returning a
class, why not implement it as class?


class gen implements generator
{
function __generator()
yield 1;
}
}

class gen extends generator
{
function __generator()
yield 1;
}
}

Calling looks for me now much less "magic":

$gen = new gen;
$gen->next();

As maintainer I see "oh, it's a magic method", it's such an iterator thingy.
Another advantage: It's not final. I could replace next() etc. with my
own implementation.
And it works more hand in hand with iterators.

Just my very primitive first thoughts as PHP-scripts-developer,
without knowing much about the implementations in other languages. :)


PS: I would like to see that yield goes hand in hand with the iterator-stuff.

PPS: Ok, maybe a change isn't really needed, but I think how to use
this in a good manner (to avoid the problems mentioned above) should
be part of the docs.

--
Regards, Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

>
>
> My first thought was how could someone reading the code see, that it
> is a generator?
>

Somewhat snarky answer: By documenting the code in the first place.

Yeah, I know, we all inherit other people's code and the other person never
writes comments.

I don't think this is as big of a problem in practice, however. If you're
looking at the function to understand what it does, you're certainly
looking at statements like "return $foo;" already, right? Why would "yield
$foo;" be any more stealthy?

You posit that future engineer will have to spend hours understanding what
generatorX does because it's 50+ lines long and original engineer isn't
around anymore, but if the function is so complex, then future engineer is
going to be spending hours whether or not it's a generator at all. Code
like that is just bad code. The fact that it's a generator isn't the
problem, nor is whether it's been explicitly flagged as such.

Hm... not really satisfied with that. For me this is a little bit
> unlogical, that just a simple function can return an object.
>
> So, how about implementing as a class? I mean: If it is returning a
> class, why not implement it as class?
>
> Because that misses the entire point of generators as simplified
iterators. What you suggest already exists, it's called: class foo
implements Iterator { /* iterator funcs */ } Also, it doesn't allow for
generators as class methods:

class foo {
function bar() {
yield 1;
}
}

Since this isn't Java, you can't really do:

class foo {
class bar implements generator {
function __generator() {
yield 2;
}
}
}

PS: I would like to see that yield goes hand in hand with the
> iterator-stuff.
>
Curious if you could expand on that. Generators are iterators, so not sure
what you're asking for.

-Sara

2012/7/23 Sara Golemon <[email protected]>:
> Curious if you could expand on that. Generators are iterators, so not sure
> what you're asking for.

It's the point which is unlogical for me. Maybe it's a question. If
the generator is an object with the implementation of an iterator, why
do we need to have it as _function_?

--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 24/07/12 18:34, Alex Aulbach wrote:
> 2012/7/23 Sara Golemon <[email protected]>:
>> Curious if you could expand on that. Generators are iterators, so not sure
>> what you're asking for.
> It's the point which is unlogical for me. Maybe it's a question. If
> the generator is an object with the implementation of an iterator, why
> do we need to have it as _function_?
>
Much easier to make an iterator with a function than as a class.

--
Andrew Faulds
http://ajf.me/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 24 ביול 2012, at 20:35, Andrew Faulds wrote:

> On 24/07/12 18:34, Alex Aulbach wrote:
>> 2012/7/23 Sara Golemon <[email protected]>:
>>> Curious if you could expand on that. Generators are iterators, so not sure
>>> what you're asking for.
>> It's the point which is unlogical for me. Maybe it's a question. If
>> the generator is an object with the implementation of an iterator, why
>> do we need to have it as _function_?
>>
> Much easier to make an iterator with a function than as a class.
>
> --
> Andrew Faulds
> http://ajf.me/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

I agree, implementing a class only for iterator may be pain sometimes, and functions is much better - especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions in class methods which can be great.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/24 Andrew Faulds <[email protected]>:
> Much easier to make an iterator with a function than as a class.

2012/7/24 Yahav Gindi Bar <[email protected]>:
> I agree, implementing a class only for iterator may be pain sometimes, and functions is much better - especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions in class methods which can be great.

Ok, why not call it "iterator" or "generator" or "huffpuff" instead of
"function"? It's just the naming, which disturbs me, because a
function is something which is, when called once finished once. I
don't like mathematics, but that is one of the definition of a
function:

http://en.wikipedia.org/wiki/Function_%28mathematics%29
"each input is related to exactly one output"

Couldn't be so complicated to introduce a new name for that, or?

--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 24/07/12 18:56, Alex Aulbach wrote:
> 2012/7/24 Andrew Faulds <[email protected]>:
>> Much easier to make an iterator with a function than as a class.
> 2012/7/24 Yahav Gindi Bar <[email protected]>:
>> I agree, implementing a class only for iterator may be pain sometimes, and functions is much better - especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions in class methods which can be great.
> Ok, why not call it "iterator" or "generator" or "huffpuff" instead of
> "function"? It's just the naming, which disturbs me, because a
> function is something which is, when called once finished once. I
> don't like mathematics, but that is one of the definition of a
> function:
>
> http://en.wikipedia.org/wiki/Function_%28mathematics%29
> "each input is related to exactly one output"
>
> Couldn't be so complicated to introduce a new name for that, or?
>
You'll love LISP, I'm sure, or maybe Python's functional subset.

But PHP functions usually have side-effects, they aren't strict
mathematical functions.

So complaining about this is rather pointless.

--
Andrew Faulds
http://ajf.me/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

You could introduce new keyword for generator... even call it "generator" but why (its kind of "design" issue...)? if the syntax that one should use in order to implement the generator is just like a function, but using yield keyword in order to return the items to store?

As long as I know, most programming languages that uses generators wrap it up in a function, so why shall we introduce new keyword that can confuse programmers?

I think using function and returning the value using yield is great... although I'm open to any new nicely-written generator syntax.

On 24 ביול 2012, at 20:56, Alex Aulbach wrote:

> 2012/7/24 Andrew Faulds <[email protected]>:
>> Much easier to make an iterator with a function than as a class.
>
> 2012/7/24 Yahav Gindi Bar <[email protected]>:
>> I agree, implementing a class only for iterator may be pain sometimes, and functions is much better - especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions in class methods which can be great.
>
> Ok, why not call it "iterator" or "generator" or "huffpuff" instead of
> "function"? It's just the naming, which disturbs me, because a
> function is something which is, when called once finished once. I
> don't like mathematics, but that is one of the definition of a
> function:
>
> http://en.wikipedia.org/wiki/Function_%28mathematics%29
> "each input is related to exactly one output"
>
> Couldn't be so complicated to introduce a new name for that, or?
>
> --
> Alex Aulbach

On 24/07/12 19:06, Yahav Gindi Bar wrote:
> You could introduce new keyword for generator... even call it "generator" but why (its kind of "design" issue...)? if the syntax that one should use in order to implement the generator is just like a function, but using yield keyword in order to return the items to store?
>
> As long as I know, most programming languages that uses generators wrap it up in a function, so why shall we introduce new keyword that can confuse programmers?
>
> I think using function and returning the value using yield is great... although I'm open to any new nicely-written generator syntax.
>
> On 24 ביול 2012, at 20:56, Alex Aulbach wrote:
>
>> 2012/7/24 Andrew Faulds <[email protected]>:
>>> Much easier to make an iterator with a function than as a class.
>> 2012/7/24 Yahav Gindi Bar <[email protected]>:
>>> I agree, implementing a class only for iterator may be pain sometimes, and functions is much better - especially when 5.3 got the anonymous functions, so we can even use the generators for iterator functions in class methods which can be great.
>> Ok, why not call it "iterator" or "generator" or "huffpuff" instead of
>> "function"? It's just the naming, which disturbs me, because a
>> function is something which is, when called once finished once. I
>> don't like mathematics, but that is one of the definition of a
>> function:
>>
>> http://en.wikipedia.org/wiki/Function_%28mathematics%29
>> "each input is related to exactly one output"
>>
>> Couldn't be so complicated to introduce a new name for that, or?
>>
>> --
>> Alex Aulbach
>
And anyway it just depends on your perspective. It's still a function
IMO, it doesn't return, it yields. To me it's kinda like having a
function in another thread that passes several messages back over its
lifetime, and then finally returns.

--
Andrew Faulds
http://ajf.me/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/24 Andrew Faulds <[email protected]>:
> But PHP functions usually have side-effects, they aren't strict mathematical
> functions.

Ah, you might mean str_tok()? Are there more, do you have a list?

But we're in PHP-programming-context. You write a function in PHP, you
call it and it will return once called. I see there no exeption.

> So complaining about this is rather pointless.

I don't complain about the past. I just think now, that if it doesn't
behave like a function it shouldn't be called function. A function
which returns as an object and is not completed is not a function.

And if other languages do so, my argument will be the same.

<rising finger with epic mimic, fistulous voice> We need not to make
the same mistake again! :)

--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 24/07/12 19:32, Alex Aulbach wrote:
> 2012/7/24 Andrew Faulds <[email protected]>:
>> But PHP functions usually have side-effects, they aren't strict mathematical
>> functions.
> Ah, you might mean str_tok()? Are there more, do you have a list?
>
> But we're in PHP-programming-context. You write a function in PHP, you
> call it and it will return once called. I see there no exeption.
>
>> So complaining about this is rather pointless.
> I don't complain about the past. I just think now, that if it doesn't
> behave like a function it shouldn't be called function. A function
> which returns as an object and is not completed is not a function.
>
> And if other languages do so, my argument will be the same.
>
> <rising finger with epic mimic, fistulous voice> We need not to make
> the same mistake again! :)
>
All the array_* functions have side effects. Most class methods, which
are also functions, have side effects. Most of the functions I write
have side effects. Much of mysql_* has side effects.

PHP is not LISP.

--
Andrew Faulds
http://ajf.me/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Em Tue, 24 Jul 2012 19:56:46 +0200, Alex Aulbach <[email protected]>
escreveu:

> 2012/7/24 Andrew Faulds <[email protected]>:
>> Much easier to make an iterator with a function than as a class.
>
> 2012/7/24 Yahav Gindi Bar <[email protected]>:
>> I agree, implementing a class only for iterator may be pain sometimes,
>> and functions is much better - especially when 5.3 got the anonymous
>> functions, so we can even use the generators for iterator functions in
>> class methods which can be great.
>
> Ok, why not call it "iterator" or "generator" or "huffpuff" instead of
> "function"? It's just the naming, which disturbs me, because a
> function is something which is, when called once finished once. I
> don't like mathematics, but that is one of the definition of a
> function:
>
> http://en.wikipedia.org/wiki/Function_%28mathematics%29
> "each input is related to exactly one output"
>

Other have already explained that PHP functions are not strictly
mathematical functions, but generators nevertheless somewhat fit that
description. When you have function foo() { ... yield /* ... */; ... } and
you call foo(), you get the same thing every time: a Generator object. It
so happens that the implementation of that object is inside the body of
the function.

Maybe this helps you reason about the feature.

--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/24 Andrew Faulds <[email protected]>:
> PHP is not LISP.

Hey, I don't want to have LISP. I just want to make complicated things
more clear, and it doesn't matter, if something else is right or wrong
in the past.

It isn't difficult to make a new keyword or something wich disticts it
a little bit more for that.

--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/24 Gustavo Lopes <[email protected]>:
> When you have function foo() { ... yield /* ... */; ... } and
> you call foo(), you get the same thing every time: a Generator object. It so
> happens that the implementation of that object is inside the body of the
> function.

Hmmm. It's not that I didn't understand it. :)

My thoughts are about usage in practice. Ok, my first argument with
the developer, who overtakes an old project was weak.
What about situations, when developers with different knowlegde work together?

Or when you have programming errors, when you write

function blubb()
{
.... yields...
....
.... return....
}

(you may only see the "return").

And many those situations are thinkable, because this kind of PHP
function works so totally different from current.


> Maybe this helps you reason about the feature.

Please understand me, it's not that I don't like it or that I couldn't
live with it. It's because I have too much experience what could
happen if new programming features are introduced.

For example: Exceptions in PHP are quite old now. And the concept of
exceptions should be known. But I worked together with programmers
wich produced code like

....
try {
$value = method_which_throws_exceptions();
} catch (...) {
return $value;
}
return $value;
....

And he has it done, although I wrote some example code for him how to
use exceptions in this context!!11!


THAT'S the reality.

We can ignore that, but I just want to make such simple mistakes not
so easy and the afford is worth the results.

You can argue: "Those mistakes will always happen". I say "Yes, of
course, but if we have the chance to reduce those mistakes we should
do it."

--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 24/07/12 20:13, Alex Aulbach wrote:
> 2012/7/24 Gustavo Lopes <[email protected]>:
>> When you have function foo() { ... yield /* ... */; ... } and
>> you call foo(), you get the same thing every time: a Generator object. It so
>> happens that the implementation of that object is inside the body of the
>> function.
> Hmmm. It's not that I didn't understand it. :)
>
> My thoughts are about usage in practice. Ok, my first argument with
> the developer, who overtakes an old project was weak.
> What about situations, when developers with different knowlegde work together?
>
> Or when you have programming errors, when you write
>
> function blubb()
> {
> ... yields...
> ...
> ... return....
> }
>
> (you may only see the "return").
>
> And many those situations are thinkable, because this kind of PHP
> function works so totally different from current.
>
>
>> Maybe this helps you reason about the feature.
> Please understand me, it's not that I don't like it or that I couldn't
> live with it. It's because I have too much experience what could
> happen if new programming features are introduced.
>
> For example: Exceptions in PHP are quite old now. And the concept of
> exceptions should be known. But I worked together with programmers
> wich produced code like
>
> ...
> try {
> $value = method_which_throws_exceptions();
> } catch (...) {
> return $value;
> }
> return $value;
> ...
>
> And he has it done, although I wrote some example code for him how to
> use exceptions in this context!!11!
>
>
> THAT'S the reality.
>
> We can ignore that, but I just want to make such simple mistakes not
> so easy and the afford is worth the results.
>
> You can argue: "Those mistakes will always happen". I say "Yes, of
> course, but if we have the chance to reduce those mistakes we should
> do it."
>
It's fairly obvious from context these aren't ordinary functions, IMO.

And anyway, what could possibly go wrong? Is there any incorrect but
non-fatal or warning-generating way you could use them?

--
Andrew Faulds
http://ajf.me/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

>
> Or when you have programming errors, when you write
>
> function blubb()
> {
> ... yields...
> ...
> ... return....
> }
>
> (you may only see the "return").
>
> But that's okay, because PHP *does* see both, and it tells you "yield may
not be used with return" in a lovely little parser error. Some developers
consider this a useful hint.

-Sara

> On 24/07/12 19:32, Alex Aulbach wrote:
>>
>> 2012/7/24 Andrew Faulds <[email protected]>:
>>>
>>> But PHP functions usually have side-effects, they aren't strict
>>> mathematical
>>> functions.
>>
>> Ah, you might mean str_tok()? Are there more, do you have a list?
>>
>> But we're in PHP-programming-context. You write a function in PHP, you
>> call it and it will return once called. I see there no exeption.
>>
>>> So complaining about this is rather pointless.
>>
>> I don't complain about the past. I just think now, that if it doesn't
>> behave like a function it shouldn't be called function. A function
>> which returns as an object and is not completed is not a function.
>>
>> And if other languages do so, my argument will be the same.
>>
>> <rising finger with epic mimic, fistulous voice> We need not to make
>> the same mistake again! :)
>>
> All the array_* functions have side effects. Most class methods, which are
> also functions, have side effects. Most of the functions I write have side
> effects. Much of mysql_* has side effects.
>
> PHP is not LISP.
>

LISP has side effects.

>
> --
> Andrew Faulds
> http://ajf.me/
>
>
> --

Trying to solve cultural problems with the programming language rarely
works. I don't think it contributes much to how well a developer will
learn the use of generators with whether we use function or another
keyword.

With that said I believe that's the point of a discussion phase and
I'd like to offer that we're free to implement it how we want.

PHP made implementation mistakes in the past that led to awkward
behavior (like objects passed by value in PHP4), but that's never
stopped things from moving forward and offering up useful features
that users want. I think putting the technical details aside the
engine can aid a developer in distinguishing between spotting
unintended side effects and preventing disastrous consequences. You
have similar issues with developers that try to execute database
queries while there are buffered results or developers that
inadvertently write infinite loops. There are enough safeguards in
place to help avoid such nuances.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/7/25 Sherif Ramadan <[email protected]>:
> PHP made implementation mistakes in the past that led to awkward
> behavior (like objects passed by value in PHP4), but that's never
> stopped things from moving forward and offering up useful features
> that users want. I think putting the technical details aside the
> engine can aid a developer in distinguishing between spotting
> unintended side effects and preventing disastrous consequences.

I like that kind of agile programming, too.

But if someone like me says "come on, lets make it a little bit more
easy, because returning objects from functions is some kind of
unconventional; many developers will make mistakes here..." - why not?
They will. I can tell by sure.

Since I begun reading this mailing list I have the impression, that
there are only PHP-programmers like us out there. But the fact is,
that the most PHP-programmers didn't even read the manuals completly.
You may say "Their fault" "Are they programmers, if they don't?", but
this is first a little bit of ignorance because second this is one of
the best features, that PHP has - this "nicely flow", everybody can do
it. I always think of Bob Ross, when I explain PHP.

But it's ok, there are no mistakes, there are just happy little accidents. :)

[means: I will not complain any more]

--
Alex Aulbach

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Alex Aulbach wrote:
>> PHP made implementation mistakes in the past that led to awkward
>> >behavior (like objects passed by value in PHP4), but that's never
>> >stopped things from moving forward and offering up useful features
>> >that users want. I think putting the technical details aside the
>> >engine can aid a developer in distinguishing between spotting
>> >unintended side effects and preventing disastrous consequences.
> I like that kind of agile programming, too.
>
> But if someone like me says "come on, lets make it a little bit more
> easy, because returning objects from functions is some kind of
> unconventional; many developers will make mistakes here..." - why not?
> They will. I can tell by sure.
>
> Since I begun reading this mailing list I have the impression, that
> there are only PHP-programmers like us out there. But the fact is,
> that the most PHP-programmers didn't even read the manuals completly.
> You may say "Their fault" "Are they programmers, if they don't?", but
> this is first a little bit of ignorance because second this is one of
> the best features, that PHP has - this "nicely flow", everybody can do
> it. I always think of Bob Ross, when I explain PHP.

The manual that I read bears no resemblance to the current one, and I still have
to find a manual that ACTUALLY explains how I should write code that it 'strict'
compliant. The bulk of the on-line boilerplates are no longer fit for purpose so
how can we expect newcomers to 'get it right first time'

> But it's ok, there are no mistakes, there are just happy little accidents.:)

That covers most of my best software :)

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

>
> I like that kind of agile programming, too.
>
> But if someone like me says "come on, lets make it a little bit more
> easy, because returning objects from functions is some kind of
> unconventional; many developers will make mistakes here..." - why not?
> They will. I can tell by sure.
>

What are suggesting is going to make this easy that isn't already
covered by the RFC? Lets not get caught up in semantics here. The
current RFC outlines what appears to be inline with other established
implementations. The fact that a function can return an object should
be nothing new to PHP. The fact that an object cause some flow of
control through a construct, also shouldn't be new to PHP.

I don't understand what you find non-conventional about functions or
methods that return objects.

function foo() {
return new bar;
}

$foo = foo();

That's already a common thing in most PHP code I see. PDO::prepare(),
MySQLi::prepare(), DateTime::diff(), also return objects as a result
of calling those methods. I don't think very many PHP developers will
find this concept difficult to grasp if they can already grasp the
aforementioned methods, for example.

>
> Since I begun reading this mailing list I have the impression, that
> there are only PHP-programmers like us out there. But the fact is,
> that the most PHP-programmers didn't even read the manuals completly.
> You may say "Their fault" "Are they programmers, if they don't?", but
> this is first a little bit of ignorance because second this is one of
> the best features, that PHP has - this "nicely flow", everybody can do
> it. I always think of Bob Ross, when I explain PHP.
>

Yes, there are people who don't read the manual. This is nothing new
or unique to any particular language. Yes, PHP makes it easy for
virtually anybody to use. No, not everything in PHP is easy. No, not
everybody who can use PHP will find it easy to write good code or to
understand all of the language's features at first. What programming
language holds this characteristic? From all of the programming
languages I've learned over the years PHP is still by far at the top
of my list for taking on new features.

Just between PHP 5.2 and 5.4 we've gained traits, closures,
namespaces, function array derefrencing, access to member upon
instantiation, and lots of other lovely additions to the language. I
don't see languages like Java or Python evolving this quickly -- by
contrast.

>
> But it's ok, there are no mistakes, there are just happy little accidents. :)
>
> [means: I will not complain any more]
>
> --
> Alex Aulbach

I didn't take any of that as a complaint. I think if you have an
object suggestion (or even subjective one) as to how this can be
easier on the end-user of the language it would be important to bring
it out now. I was unable to ascertain from the prior discussion thus
far.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Sherif Ramadan wrote:
> Just between PHP 5.2 and 5.4 we've gained traits, closures,
> namespaces, function array derefrencing, access to member upon
> instantiation, and lots of other lovely additions to the language. I
> don't see languages like Java or Python evolving this quickly -- by
> contrast.

But now we also need the people who insisted that these were essential coming up
to the plate and producing good documentation on how they should be used
properly. As yet they are not adding anything to MY existing code base except
hassle.

All these 'extras' may seem 'sexy' to some people, but if there is no pressing
need to use them why would many of us bother? Apart from later having to debug
some third party library that has been 'sexed up' with the latest gismoes and
which is almost unreadable due to the shortcuts it uses.

( I'll start a new thread for my other rant ... )

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

>
>
> ( I'll start a new thread for my other rant ... )


nah, you won't, you will bring that up in every thread instead.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

>> Just between PHP 5.2 and 5.4 we've gained traits, closures,
>> namespaces, function array derefrencing, access to member upon
>> instantiation, and lots of other lovely additions to the language. I
>> don't see languages like Java or Python evolving this quickly -- by
>> contrast.
>
>
> But now we also need the people who insisted that these were essential
> coming up to the plate and producing good documentation on how they should
> be used properly. As yet they are not adding anything to MY existing code
> base except hassle.
>
> All these 'extras' may seem 'sexy' to some people, but if there is no
> pressing need to use them why would many of us bother? Apart from later
> having to debug some third party library that has been 'sexed up' with the
> latest gismoes and which is almost unreadable due to the shortcuts it uses.
>
> ( I'll start a new thread for my other rant ... )
>

I don't see anything about these particular features that isn't
already documented. Albeit there are parts of the documentation that
could always use a bit of refinement every now and then. With that
said, the manual isn't a place to tell people "how" a particular
feature should be used, but how it "can" be used and to what
consequence. The actual use is left up to the developer and we all
know there is more than one way any given developer likes to implement
things in any language.

In an effort not to devolve this thread into something it's not I'd
like to reposition that towards generators.

In order for PHP features to end up getting implemented and committed
into PHP there's a lot of real estate invovled. For one, you have to
have enough developer interest around the feature to begin with. In
the last 24 hours alone there has been significant activity in this
thread (and over 50 responses total in the last few weeks). Two, you
need the have core developers motivated enough to spend the time in
actually writing up the implementation and getting it shipped. That
involves a lot of other intricate work so someone that isn't focused
or motivated enough isn't going to get very far. This also means more
core developers have to jump in if the feature gets into a release
version where maintenance and bug fixes come into play (after all you
can't test everything until you release it into the wild and get
people to discover new edge cases). Three, it has to prove useful
enough that people could not easily achieve the functionality without
language addition. Otherwise it eventually becomes tainted and dies
off (take mysql_* as an example).

All the PHP developers I've spoken with over the past few weeks that
now about the generators RFC are very excited to see it come to PHP.
Especially those developers that have worked with generators in other
languages and know of its usefulness. As for those who don't know
about it yet -- give them a chance. They may like it (of course some
may not). We're not here to discuss it's popularity, but it's
usefulness and feasibility. It's too early to start debating anything
else.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Like they have already... :/


Sent from Samsung Mobile

Ferenc Kovacs <[email protected]> wrote:

>
>
> ( I'll start a new thread for my other rant ... )


nah, you won't, you will bring that up in every thread instead.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Sherif Ramadan wrote:
> I don't see anything about these particular features that isn't
> already documented. Albeit there are parts of the documentation that
> could always use a bit of refinement every now and then. With that
> said, the manual isn't a place to tell people "how" a particular
> feature should be used, but how it "can" be used and to what
> consequence. The actual use is left up to the developer and we all
> know there is more than one way any given developer likes to implement
> things in any language.

My only 'complaint' is that while there is a lot of 'documentation' it is all
somewhat fragmented. There is nothing which provides a 'good practice' guide,
and all of the examples returned by google searches nowadays are well behind the
times. Everything is well documented in it's own little niche, but nothing
provides a guide to link the whole into a coherent 'strict compliant' practice?

Generators are scratching another itch, from a base that I never started from.
My CSV scanners have always read in and processed blocks of data. The
fundamental mistake in the rfc is 'getLinesFromFile' not processing each line as
it is loaded. I do a LOT of database data processing which 'generate' results
sets, and the example of 'rewinding a generator' is much better handled by a
function that handles the cursor position on the data set. So I'm still not
seeing anywhere that 'generator' has a pressing application? Perhaps because I
already have library code that scratches the particular itch?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Generators aren't for you, then, they are for people like me who, for example, used a C# generator for yielding tokens, or, for example, use generators to iterate element by element through multi-dimensional arrays.

--
Sent from Samsung Mobile
Andrew Faulds
http://ajf.me/

Lester Caine <[email protected]> wrote:

Sherif Ramadan wrote:
> I don't see anything about these particular features that isn't
> already documented. Albeit there are parts of the documentation that
> could always use a bit of refinement every now and then. With that
> said, the manual isn't a place to tell people "how" a particular
> feature should be used, but how it "can" be used and to what
> consequence. The actual use is left up to the developer and we all
> know there is more than one way any given developer likes to implement
> things in any language.

My only 'complaint' is that while there is a lot of 'documentation' it is all
somewhat fragmented. There is nothing which provides a 'good practice' guide,
and all of the examples returned by google searches nowadays are well behind the
times. Everything is well documented in it's own little niche, but nothing
provides a guide to link the whole into a coherent 'strict compliant' practice?

Generators are scratching another itch, from a base that I never started from.
My CSV scanners have always read in and processed blocks of data. The
fundamental mistake in the rfc is 'getLinesFromFile' not processing each line as
it is loaded. I do a LOT of database data processing which 'generate' results
sets, and the example of 'rewinding a generator' is much better handled by a
function that handles the cursor position on the data set. So I'm still not
seeing anywhere that 'generator' has a pressing application? Perhaps because I
already have library code that scratches the particular itch?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Andrew Faulds wrote:
> Generators aren't for you, then, they are for people like me who, for example,
> used a C# generator for yielding tokens, or, for example, use generators to
> iterate element by element through multi-dimensional arrays.
Such as the family tree created by iterating through a GEDCOM file?
We build a searchable copy of the data in a database and use SQL tools for
interrogating the results.
And build result set arrays direct from the database. So perhaps I just don't
have any use for the concept with my methods of working ...

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php