Re: Re: [PHP-DEV] removing an item from an array
On 2012-08-19 04:08, Levi Morrison wrote: On Sat, Aug 18, 2012 at 12:42 AM, Alexey Zakhlestin wrote: On 16.08.2012, at 0:18, Rasmus Schultz wrote: How come there is no straight-foward obvious way to simply remove a given value from an array? Well, this sounds like a reason for creating SplSet class There's already SplObjectStorage which CAN act like a Set for objects only. It's a terrible solution in my opinion and am working on creating a proper one. I don't know if that effort will be accepted, but I wanted to point out that a set already exists in the SPL. SplObjectStorage would indeed cover one given example: On 2012-08-19 10:18, Andrew Faulds wrote: > Hmm. I can think of a particular instance I've needed to remove an > item from an array by value, and where keys wouldn't be an option. In > PHP you can only have string or int keys, you can't have object keys. > In Python, I've used Twisted (an excellent asynchronous OOP > networking framework) to write client-server applications. One thing > I did was maintain a list of clients (that is, a Python list). When a > client disconnected, I would do list.remove(client). Of course there > might be better ways to implement this, but it was simple and worked. > Anything wrong with allowing the same in PHP? > SplObjectStorage even has a detach() method for removing an element by value, as well as implementing the various array access interfaces. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE]Call for voting: support use list in foreach
On Sat, Aug 18, 2012 at 5:48 PM, Nikita Popov wrote: > On Sat, Aug 18, 2012 at 6:34 AM, Laruence wrote: >> Hi: >> This feature introduces list() support in foreach constructs(more >> info can be found here: https://wiki.php.net/rfc/foreachlist). >> >> please vote for this: https://wiki.php.net/rfc/foreachlist#vote > > Hi Lauruence! > > Is this vote just for list() or also for error suppression? I'd vote > +1 on the first, but -1 on the second, so it would be nice to make it > more clear ;) Hi, okey, I opened another vote for the foreach list with silent token supporting. thanks > > Nikita -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
Hi! > For PHP we would need to have some similar behavior. PHP's current > exception model is incompatible with GeneratorExitException (because > PHP does not have BaseExceptions). So what I'd probably do instead is > monkeypatch a ZEND_RETURN opcode at the current execution position and Patching opcodes is not a good idea, since opcodes could be cached, and the cache can be shared between different processes. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On 19/08/12 01:39, Morgan L. Owens wrote: On 2012-08-19 10:25, Andrew Faulds wrote: On 18/08/12 14:52, Morgan L. Owens wrote: How simple is it? Does it: 1) Remove one occurrence of the element (presumably the first) or all? 2) Reindex the array (as someone else argued was necessary to make it "properly indexed" afterwards) or not? 3) Modify the array in-place or return a modified array? 4) Use type-strict or normal comparisons? So to answer you, 1) one, 2), no, 3) in-place, 4) type-strict (I don't see how a weakly-typed comparison for identifying an array value would help anyone). So ... using a different definition of "value" than that used by array_search() and array_keys(), then? Assuming you mean the strictness of comparison, you could have an optional $strict parameter defaulting to false like array_search(). (and hence non-strict by default) -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On 2012-08-19 10:25, Andrew Faulds wrote: On 18/08/12 14:52, Morgan L. Owens wrote: How simple is it? Does it: 1) Remove one occurrence of the element (presumably the first) or all? 2) Reindex the array (as someone else argued was necessary to make it "properly indexed" afterwards) or not? 3) Modify the array in-place or return a modified array? 4) Use type-strict or normal comparisons? So to answer you, 1) one, 2), no, 3) in-place, 4) type-strict (I don't see how a weakly-typed comparison for identifying an array value would help anyone). So ... using a different definition of "value" than that used by array_search() and array_keys(), then? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On 18/08/12 14:52, Morgan L. Owens wrote: Rasmus Schultz wrote: > I disagree - this is (or should be) a simple, atomic operation... > yet, you've got a function-call, an intermediary variable, a boolean > test, and an unset statement repeating the name of the array you're > deleting from. > > This should be a simple statement or function/method-call, and in > most other languages it would be... How simple is it? Does it: 1) Remove one occurrence of the element (presumably the first) or all? 2) Reindex the array (as someone else argued was necessary to make it "properly indexed" afterwards) or not? 3) Modify the array in-place or return a modified array? 4) Use type-strict or normal comparisons? Personally, I like Python's list.remove(x), which I think might be what he wants. Certainly it's what I want when I need to remove a list item. See: http://docs.python.org/tutorial/datastructures.html* *According to the docs, it does this: " Remove the first item from the list whose value is/x/. It is an error if there is no such item." So to answer you, 1) one, 2), no, 3) in-place, 4) type-strict (I don't see how a weakly-typed comparison for identifying an array value would help anyone). That's sixteen different interpretations of "remove a given value from an array" right there. Leave support for any of them out and someone is going to complain that they have to write a function to do what should be a "simple statement". Support all of them and there will probably _still_ be someone who wants their own particular set of circumstances catered for without having to write their own function to do it. Just my 2¢. -- Andrew Faulds http://ajf.me/
Re: [PHP-DEV] Combined assignment operator for short ternary
On 18/08/12 03:36, Tjerk Meesters wrote: Sent from my iPhone On 18 Aug, 2012, at 5:41 AM, Sebastian Krebs wrote: Hi, Don't know, how complicated this is (and also someone (not me) must implement it, because I can't :X), but to be in sync with the operators the short ternary operator should be usable in conjunction with the assignment like the other binary operators. Don't know, if anybody understands me :D So here is an example // instead of $foo = $foo ?: 'default'; // Just $foo ?:= 'default'; Why not just: $foo ?= 'default'; Just noting, I made a ML email earlier about this, except it would be shorthand for isset($lval) ? $lval : $default. And this has been brought up before several times. I have many of this "default assigments" and yes: This is just syntactic sugar. Regards, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] re: removing an item from an array
On 17/08/12 22:41, Rasmus Lerdorf wrote: On 08/17/2012 05:35 PM, Rasmus Schultz wrote: Most other languages have more than one collection-type... since PHP has only the single, hybrid array-type which acts both as a hash and as an array, something like this ought to be available. I don't know why everyone is so eager to jump up and argue against something this simple, basic and useful. The fact that this is missing is an oversight - just look at the number of solutions people come up with. For what? I want to remove and object from a list. Not an exotic and crazy requirement, is it? It just isn't the sort of thing that should require any substantial thinking or typing. And it doesn't help make codebases more legible when people come up with 25 different ways to do it. The problem is that it is a rather unusual thing to do. I don't mean removing an element, that is very common, but you are implying that you know you don't have duplicates and you want a fast way to remove an element by value in that case. To me that means you built your array badly. If the values are unique then they should be the keys, or at least a representation of the value should be the key such that you don't need to scan the entire hash for the element when you need to access it. And removal is just like any other access. -Rasmus Hmm. I can think of a particular instance I've needed to remove an item from an array by value, and where keys wouldn't be an option. In PHP you can only have string or int keys, you can't have object keys. In Python, I've used Twisted (an excellent asynchronous OOP networking framework) to write client-server applications. One thing I did was maintain a list of clients (that is, a Python list). When a client disconnected, I would do list.remove(client). Of course there might be better ways to implement this, but it was simple and worked. Anything wrong with allowing the same in PHP? -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
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 array, or whether it is a generator (or maybe even returns a hand-implemented iterator). It's just all the same. The fact that the function uses `yield` internally is just an implementation detail, not something that has to be part of the public API. Actually you can swap between an array and generator implementation just by replacing one line in the function body (yield <=> $array[])... Then I am now totally confused ... I was under the impression that the IDEA was that EACH call to a generator would return the next value? So you do not get an array built. Just as one would with SUSPEND in an SQL query process. The only value available is the current one, and one processes that. So that the user of a generator needs to handle the results sequentially rather than simply accessing the array of results. There does not need to be an array of results, only the processed output of each cycle of the generator? This of cause may still be confused thinking, since I would never be working in the way that this stuff is supposed to simplify. I WOULD be handling each element as I read it and building the details required from each cycle of the process. getLinesFromFile() would only ever return an array if that is what was needed to build the resulting page. It would normally be processed into a database, and later the required information selected from that. But that is a specialist iterator process just built with simple PHP. -- 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
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
( resending with correct formatting, and missing context while at it, sorry about that ) On Aug 15, 2012, at 8:33 PM, Nikita Popov wrote: > (...) > > Another aspect here is that there is no reasonable syntax for this > feature, at least I can't think of one: > > * The syntax `$foo = (InterfaceName) $container->service` is > completely out of question. It looks like a cast, but wouldn't > actually do a cast. > * Same is to be said about `InterfaceName $foo = > $container->service`. This syntax implies that the $foo variable will > always be of type InterfaceName, even if it is later reassigned. It's > not a sensible syntax for a one time validation > * The other three syntaxes that were mentioned were just as unclear. > E.g. `$foo = $container->service as InterfaceName` again looks like a > strange cast syntax and `$foo = $container->service is InterfaceName` > looks like the assignment should evaluate to a boolean (i.e. `is` is > some kind of `instanceof`). good points In addition, the root cause that triggered this proposal in the first place: serve container / object registry doc issue, is kind of moot, ref bellow. > > On the other hand, the current ways of accomplishing the same goal are > well-established and easy to understand: > > * Using a docblock: /** @var $foo IntefaceName **/ > * Using an assertion: assert($foo instanceof InterfaceName). > > I think that the assertion is a rather concise and clear way to do > this. It is much more obvious than some new and obscure `$foo = > (InterfaceName $container->service)` syntax. To expand on that, @Stan: If you make sure you configure your container to injection dependencies (and in case of lazy loading, inject factories* with type hinting in doc) instead of passing the [dependency injection] container around as a registry, then you almost don't get this problem at all, and you will avoid introducing container awareness/dependency in your architecture. Only place you will have this original problem though is in the code that gets the first dependency of the execution, like in index.php for instance, but even then you can have Container interface for the most common root dependencies. In the cases that doesn't fit, you should plainly use the doc block referred to by Nikita, it is already supported by IDE's and won't need additional 3 years to get support. * As alternatives to factories with or without container knowledge, there is one alternative that some containers support: Proxy objects: container generates proxy objects whenever you want dependencies to be lazy loaded, they have container awareness, but this becomes 100% transparent to your code, but it probably adds some overhead. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
On Sat, Aug 18, 2012 at 12:42 AM, Alexey Zakhlestin wrote: > > On 16.08.2012, at 0:18, Rasmus Schultz wrote: > >> How come there is no straight-foward obvious way to simply remove a given >> value from an array? > > Well, this sounds like a reason for creating SplSet class > There's already SplObjectStorage which CAN act like a Set for objects only. It's a terrible solution in my opinion and am working on creating a proper one. I don't know if that effort will be accepted, but I wanted to point out that a set already exists in the SPL. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
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? HAVING to work through a functions code
> simply to see if it contains a 'yeild' so as to understand that it's not
> going to give a normal return seems insane? Alright the function can be
> properly documented with a docblock, but if it isn't ...
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
array, or whether it is a generator (or maybe even returns a
hand-implemented iterator). It's just all the same. The fact that the
function uses `yield` internally is just an implementation detail, not
something that has to be part of the public API. Actually you can swap
between an array and generator implementation just by replacing one
line in the function body (yield <=> $array[])...
>>> generator function getLinesFromFile($fileName) {
>>> if (!$fileHandle = fopen($fileName, 'r')) {
>>>return;
>>>}
>>
>>> There is an existing generator implementation in HipHop PHP, which
>>> uses automatic-detection. Using the asterix modifier would break
>>> compatibility.
>>
>> This should not be a concern, sure, it's annoying for the hiphop
>> developers but they chose to copy and then *chance* the PHP language for
>> their own effect.
>>
>>> yield: Yields the value null with an auto-incrementing integer key.
>> What is the usecase for this?
> I can see some interesting porting problems with this ... one of the stock
> changes when moving from a MySQL only setup to support other databases is
> to remove the auto-increment magic, and replace it with proper sequence
> code prior to inserting. I can see translating a 'MySQL' geared generator
> into a more general one as being impossible if some tricks like this are
> used.
Generators are supposed to act very similar to array-returning
functions, so they also have similar key semantics. If you do
$result[] = $foo; that will behave the same as doing yield $foo;. Both
will use an auto-incrementing key.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
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 necessity? HAVING to work through a functions code > simply to see if it contains a 'yeild' so as to understand that it's not > going to give a normal return seems insane? Alright the function can be > properly documented with a docblock, but if it isn't ... I don't see how that is any different from having to look through a function to see if it is a void function or if it returns something, and if so, what it returns. Or checking to see if it outputs something. PHP is very dynamic. A function can be both void and non-void at the same time. It can return mixed types and do pretty much anything you can imagine. I don't really see what the generator keyword achieves. What happens if I have a function that I mark as a generator but then I don't put a yield in it? Is that a compile-level error? That might work, but then what if I put a yield in it but the logic of the function never gets to it: if(cond) return [1,2,3]; else if(other_cond) yield $val; else return; There is no way to know at compile-time whether the yield will ever be reached. To me it seems odd to have a generator keyword that cannot be enforced and doesn't mean anything other than stating a developer's intent. Whether the developer actually carried through and implemented the intended generator can only be verified by reading the code. This smells much more like a source comment to me. If we were going to go with a generator keyword, then I think the feature needs to be completely re-thought. I would suggest dropping the yield keyword entirely and having return be equivalent to a yield if the function is marked as a generator. Then the keyword actually does something. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
> 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 voting on it".
>>
>> https://wiki.php.net/rfc/generators
>>
>> If you have any further feedback, now would be a good time to raise
>> it. If there is something you previously posted, but which I didn't
>> yet address, please let me know. There were around 150 mails and I
>> sure missed some of them.
>
> 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 generator functions are
>> marked with an asterix modifier (function*). This method has the
>> advantage that generators are more explicit and also allows for
>> yield-less coroutines.
>>
>> The automatic detection was chosen over the asterix modifier for the
>> following reasons:
>
> 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":
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? HAVING to work through a functions code
simply to see if it contains a 'yeild' so as to understand that it's not
going to give a normal return seems insane? Alright the function can be
properly documented with a docblock, but if it isn't ...
>> generator function getLinesFromFile($fileName) {
>> if (!$fileHandle = fopen($fileName, 'r')) {
>>return;
>>}
>
>> There is an existing generator implementation in HipHop PHP, which
>> uses automatic-detection. Using the asterix modifier would break
>> compatibility.
>
> This should not be a concern, sure, it's annoying for the hiphop
> developers but they chose to copy and then *chance* the PHP language for
> their own effect.
>
>> yield: Yields the value null with an auto-incrementing integer key.
> What is the usecase for this?
I can see some interesting porting problems with this ... one of the stock
changes when moving from a MySQL only setup to support other databases is
to remove the auto-increment magic, and replace it with proper sequence
code prior to inserting. I can see translating a 'MySQL' geared generator
into a more general one as being impossible if some tricks like this are
used.
(Out in an exhibition hall this weekend so not able to follow properly)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] re: removing an item from an array
Rasmus Schultz wrote: > I disagree - this is (or should be) a simple, atomic operation... > yet, you've got a function-call, an intermediary variable, a boolean > test, and an unset statement repeating the name of the array you're > deleting from. > > This should be a simple statement or function/method-call, and in > most other languages it would be... How simple is it? Does it: 1) Remove one occurrence of the element (presumably the first) or all? 2) Reindex the array (as someone else argued was necessary to make it "properly indexed" afterwards) or not? 3) Modify the array in-place or return a modified array? 4) Use type-strict or normal comparisons? That's sixteen different interpretations of "remove a given value from an array" right there. Leave support for any of them out and someone is going to complain that they have to write a function to do what should be a "simple statement". Support all of them and there will probably _still_ be someone who wants their own particular set of circumstances catered for without having to write their own function to do it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
On Thu, Aug 9, 2012 at 4:49 AM, Sherif Ramadan wrote:
>>
>> One question, though: It looks based on the voting like finally {} blocks
>> are going in. So... what should happen in the following situation:
>>
>> function stuff() {
>> try {
>> foreach (range(1, 100) as $i) {
>> yield $i;
>> }
>> }
>> finally {
>> print "All done";
>> }
>> }
>>
>> Does "All done" get printed once, or 101 times? Similarly:
>>
>> function things() {
>> $i = 1;
>> try {
>> while (true) {
>> yield $i++;
>> }
>> }
>> finally {
>> print "All done";
>> }
>> }
>>
>> That will run indefinitely. So will "All done" ever print, or does that
>> finally become unreachable?
>>
>> (I have no clue what the behavior "should" be in these cases, just that it
>> should be sorted out sooner rather than later.)
>>
>
>
> Based on my understanding of both RFCs, I don't see that this would be
> a conflict or lead to unexpected behavior. As stated by the generators
> RFC: "When you first call the generator function ($lines =
> getLinesFromFile($fileName)) the passed argument is bound, but nothing
> of the code is actually executed. Instead the function directly
> returns a Generator object.".
>
> So in the event we are calling the function stuff(), nothing should
> actually be executed, and as we iterate over the traversable object
> the generator should be "passing control back and forth between the
> generator and the calling code". This would be indicated by the
> "yield" keyword present in the function. Meaning you should see the
> expected result and finally should only ever be called once in your
> first example.
>
> As for you second example... Obviously if you've created an infinite
> loop you've made everything outside of the loop unreachable, whether
> you're using generators or not.
>
> However, I'll let the author of the RFC provide any clarification or
> corrections where I might be wrong.
Ooops, accidentially hit "Send" too early. So again:
Yes, that is basically right. The one interesting case that arises
when using generators is what happens when you close a generator
before it is finished. E.g. in the function mentioned above:
function stuff() {
try {
foreach (range(1, 100) as $i) {
yield $i;
}
} finally {
print "All done";
}
}
If you now create the generator, do 50 iterations and then close it:
$gen = stuff();
foreach (stuff() as $i) {
if ($i == 50) break;
}
unset($gen);
In that case the code (normally) would never reach the "finally"
clause, simply because it isn't resumed anymore.
Python solved this problem by throwing a GeneratorExitException into
the generator when it is closed. So when unset($gen) is called an
exception is thrown at the yield-stackframe and the generator resumed.
This then invokes usual exception bubbling and runs finally clauses.
When the GeneratorExitException bubbles out of the generator function
is implicitly caught and discarded.
For PHP we would need to have some similar behavior. PHP's current
exception model is incompatible with GeneratorExitException (because
PHP does not have BaseExceptions). So what I'd probably do instead is
monkeypatch a ZEND_RETURN opcode at the current execution position and
resume the generator. This would then invoke any finally clauses
through the usual processes. This should be a very transparent process
that "just works" without the need for any strange exception hacks.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
On Thu, Aug 9, 2012 at 4:49 AM, Sherif Ramadan wrote:
>>
>> One question, though: It looks based on the voting like finally {} blocks
>> are going in. So... what should happen in the following situation:
>>
>> function stuff() {
>> try {
>> foreach (range(1, 100) as $i) {
>> yield $i;
>> }
>> }
>> finally {
>> print "All done";
>> }
>> }
>>
>> Does "All done" get printed once, or 101 times? Similarly:
>>
>> function things() {
>> $i = 1;
>> try {
>> while (true) {
>> yield $i++;
>> }
>> }
>> finally {
>> print "All done";
>> }
>> }
>>
>> That will run indefinitely. So will "All done" ever print, or does that
>> finally become unreachable?
>>
>> (I have no clue what the behavior "should" be in these cases, just that it
>> should be sorted out sooner rather than later.)
>>
>
>
> Based on my understanding of both RFCs, I don't see that this would be
> a conflict or lead to unexpected behavior. As stated by the generators
> RFC: "When you first call the generator function ($lines =
> getLinesFromFile($fileName)) the passed argument is bound, but nothing
> of the code is actually executed. Instead the function directly
> returns a Generator object.".
>
> So in the event we are calling the function stuff(), nothing should
> actually be executed, and as we iterate over the traversable object
> the generator should be "passing control back and forth between the
> generator and the calling code". This would be indicated by the
> "yield" keyword present in the function. Meaning you should see the
> expected result and finally should only ever be called once in your
> first example.
>
> As for you second example... Obviously if you've created an infinite
> loop you've made everything outside of the loop unreachable, whether
> you're using generators or not.
>
> However, I'll let the author of the RFC provide any clarification or
> corrections where I might be wrong.
Yes, that is basically right. The one interesting case that arises
when using generators is what happens when you close a generator
before it is finished. E.g. in the function mentioned above:
function stuff() {
try {
foreach (range(1, 100) as $i) {
yield $i;
}
} finally {
print "All done";
}
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
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 generator functions are >> marked with an asterix modifier (function*). This method has the >> advantage that generators are more explicit and also allows for >> yield-less coroutines. >> >> The automatic detection was chosen over the asterix modifier for the >> following reasons: > > 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": There was already a rather long discussion on this topic. Most of it is noise, but I filtered out a few mails from Sara and Rasmus as they probably are of most interest: http://markmail.org/message/xzhdhbjozb4yrhh3 http://markmail.org/message/ryhygtimpd7q2nok http://markmail.org/message/32fklwqykpk56iph http://markmail.org/message/w2kbh7psplnmctcr >> yield: Yields the value null with an auto-incrementing integer key. > > What is the usecase for this? Use case is `$data = yield;`. In that case you don't care about what you yield (so just the default value and key are yielded), you are only interested in what you get sent back. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
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 voting on it".
>
> https://wiki.php.net/rfc/generators
>
> If you have any further feedback, now would be a good time to raise
> it. If there is something you previously posted, but which I didn't
> yet address, please let me know. There were around 150 mails and I
> sure missed some of them.
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 generator functions are
> marked with an asterix modifier (function*). This method has the
> advantage that generators are more explicit and also allows for
> yield-less coroutines.
>
> The automatic detection was chosen over the asterix modifier for the
> following reasons:
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":
> generator function getLinesFromFile($fileName) {
> if (!$fileHandle = fopen($fileName, 'r')) {
>return;
>}
> There is an existing generator implementation in HipHop PHP, which
> uses automatic-detection. Using the asterix modifier would break
> compatibility.
This should not be a concern, sure, it's annoying for the hiphop
developers but they chose to copy and then *chance* the PHP language for
their own effect.
> yield: Yields the value null with an auto-incrementing integer key.
What is the usecase for this?
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
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(), it would be unexpected to receive an error for calling it. A no-op is the current behavior. The issue with that is that you could accidentally reuse an already depleted (or partially depleted) generator. I.e. you run it through one loop and then through another one. With a no-op rewind it would be hard to figure out what the issue is. The error makes clear that you tried to iterate an already iterated generator. Furthermore, if you indeed *want* to partially traverse a generator in several loops, you can simply wrap it in a NoRewindIterator. This has the additional benefit of making it more clear what you want to do. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE]Call for voting: support use list in foreach
On Sat, Aug 18, 2012 at 6:34 AM, Laruence wrote: > Hi: > This feature introduces list() support in foreach constructs(more > info can be found here: https://wiki.php.net/rfc/foreachlist). > > please vote for this: https://wiki.php.net/rfc/foreachlist#vote Hi Lauruence! Is this vote just for list() or also for error suppression? I'd vote +1 on the first, but -1 on the second, so it would be nice to make it more clear ;) Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
