2012/7/25 Sara Golemon <poll...@php.net>: >> Fact: yield/generators is more or less complicated, this shouldn't be >> changed - it's a proven concept. > > Speaking of parse errors, I'm having trouble parsing this line. I *think* > you're saying that generators are just complex things and that's the way it > should be. I... guess I agree, though I have a lower opinion on the > complexity of generators. Seem like a fairly straightforward concept to me. > They are certainly proven concepts.
I'm willing to say "ok, there we have a new concept, let's put it into PHP". So I'm willing to support this - under some circumstances. You say, na, it's not so proven. Maybe, this can't be proven, but that's why I'm doing this discussion. :) In the end we mean the same, but different aspects. >> Fact: It doesn't matter how it is implemented in other languages, >> because we talk about PHP and not other languages. > > Disagree somewhat. Part of PHP's ease-of-use it it's similarity to other > languages so that a developer working on C or Perl or Java or what-have-you, > can look at PHP code for the first time and have a pretty good idea of > what's going on. Mirroring existing implementations should certainly be a > consideration for that purpose. Not the end-all decider, but a > consideration. See my last suggestion (yielder instead of generator). If my english is not too poor, I would say, that every C or Perl developer etc. will understand what is meant. I think the change is so small, that anybody who knows the concept will understand. >> Fact: This is also good style in general: Call the things what they are. > > I'll grant this point has merit, however it has two counter-arguments. (1) > T_GENERATOR naming conflict mentioned above. (2) Generators *are* still > functions, so the name "function" isn't a misnomer. They're just a special > type of function similar to how methods are special types of functions, but > we still label them as "function". For (1) see new suggestion, for (2) I would say this is not logical. First you say it's different (I removed that quote), now you say it's still a function (=not different). Can we agree with: If they're different renaming is a good style. If not, we don't need to rename it. >> Fact: as PHP-developer we must try to avoid making things more >> complicated, because this is one of the best features of PHP. > > Agreed. And a generator is far less complex than a full iterator > implementation. Further, continuation functionality is far less complex > than building in loop counting logic to an iterator's next() method. I never argued against it. I argue against how it is implemented into PHP. >> Experience: Most PHP programmers will have problems to understand >> generators because it is a function that generates an iterator... >> >> something magic <eyesroll> they never heard of before. > > Fact: PHP's manual is the best in the industry. PHP developers know this. > PHP developers are smarter than you give them credit for. The best doc is senseless, if you don't have time to read it. I don't think they're dumb. But the mass of them is in average not so experienced as the mass of other PL, because there is more mass. >> Experience: generators/yield can't be explained on one page. Much >> programmers will never ever read so much docs. :) > > The core of what a generator is can be explained in a single paragraph with > a few examples - Just like nearly every page in the PHP manual. If we can't > give PHP developers that much credit, then we should shut the project down > now. It's my experience. And can I tell you: Most times it works. Astonishing - I couldn't work like this. >> Experience: good features are self-explaining. A function which >> returns an iterator because of a simple word in it's body is not. > > A developer who's never seen the yield keyword before need only learn what > it is once. http://php.net/yield Problem (to be) solved. And my experience is also, the best documentation is self-explanation. function bla() { yield.} isn't self explanatory. But yielder bla() { yield } is. (Or let's say more self-explanatory than just function.) >> Experience: They will make stupid mistakes, because they mix yield >> function with normal functions. > > And the compiler will slap them for it. The idiots are always smarter. :) "And why do we need to look into the error-log? Too much warnings to see anything." "Error-log? I turned it off, because this bullshit caused that the discs run full." >> Experience: They will make stupid mistakes, because they will look for >> "return" instead for "yield". > > And they won't find it, but hey look, what's this yield thing, I wonder what > that does: http://php.net/yield "Fine, a function without return value. Must be the bug I searched for. WTF has this programmer made there? I remove the call and everything will work fine. Trying it out, voilla it works, the script doesn't fail anymore..." Just one of millions of possibilities. >> Experience: Not using the same name will remove a little bit pressure >> from "busy" programmers > > Developers who work with other people's code (and that's who you're talking > about) routinely have to spend time understanding the purpose of a given > function. To assume that one can pretend to understand a function without You dream. You don't have time. You need to get things done. :) > having seen and questioned an unfamiliar keyword like "yield" is ridiculous > from the outset. In 50 lines of code yield will be just overseen. But I meant something different: I thought of documentation. Maybe someone reads the docs. Really! In the docs he will find functions. And in the function this "yield". He dosn't want to know that. It makes stress. "Why do I need to know how yield functions work, I barely understand functions." So this is systematically wrong. Right would be, that yield is an own chapter. Will be easier if a generator is not a function. -- Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
