Re: [PHP-DEV] [RFC] Arrow functions / short closures

2019-03-13 Thread David Rodrigues
I have two doubts about the RFC: 1. Your example with "($x) => $x" consider the use of "$x => $x", but not specifically "($x) => $x". I mean: maybe it can accept "($x) => $x" but not "$x => $x" because of the array conflict (as mentioned), and with that we avoid to create a new keyword "fn". So

Re: [PHP-DEV] RFC Draft: Comprehensions

2019-03-13 Thread Larry Garfield
On Wed, Mar 13, 2019, at 6:30 PM, Rowan Collins wrote: > On 13/03/2019 21:10, Dik Takken wrote: > > So in practice, I expect that > > using comprehensions as proposed in the new RFC will also require doing > > a lot of iterator_to_array(). A dual comprehension syntax could fix that. > > > At

Re: [PHP-DEV] [RFC] Arrow functions / short closures

2019-03-13 Thread Larry Garfield
On Wed, Mar 13, 2019, at 11:57 AM, Nikita Popov wrote: > Hi internals, > > Motivated by the recent list comprehensions RFC, I think it's time we took > another look at short closures: > > https://wiki.php.net/rfc/arrow_functions_v2 > > This is based on a previous (withdrawn) proposal by Levi &

Re: [PHP-DEV] [RFC] Arrow functions / short closures

2019-03-13 Thread Björn Larsson
Den 2019-03-13 kl. 16:56, skrev Nikita Popov: Hi internals, Motivated by the recent list comprehensions RFC, I think it's time we took another look at short closures: https://wiki.php.net/rfc/arrow_functions_v2 This is based on a previous (withdrawn) proposal by Levi & Bob. It uses the syntax

Re: [PHP-DEV] RFC Draft: Comprehensions

2019-03-13 Thread Rowan Collins
On 13/03/2019 21:10, Dik Takken wrote: So in practice, I expect that using comprehensions as proposed in the new RFC will also require doing a lot of iterator_to_array(). A dual comprehension syntax could fix that. At risk of complicating things further, might the solution to that be to have

Re: [PHP-DEV] RFC Draft: Comprehensions

2019-03-13 Thread Kalle Sommer Nielsen
Hi Den tir. 12. mar. 2019 kl. 18.36 skrev Chase Peeler : > I've never liked "developers might use it wrong" as reason to not implement > something, especially if hard to read/complex code is the worst impact to > improper use. Me neither to be fair, but I think it is a fair consideration to

Re: [PHP-DEV] RFC Draft: Comprehensions

2019-03-13 Thread Dik Takken
On 11-03-19 05:29, Larry Garfield wrote: > Sara and I tried putting the expression first, as in Python, but that made > the lexer very unhappy There is another possible reason to put the expression last: It preserves the ordering of the intended foreach loop. What I mean to say is this: One can

Re: [PHP-DEV] [RFC] Arrow functions / short closures

2019-03-13 Thread Ben Ramsey
> On Mar 13, 2019, at 15:56, Rowan Collins wrote: > > I suggest you both read the RFC; about half the page is dedicated to > summarising the syntaxes which have been considered, and the pros and cons of > each. > > The summary of that syntax begins: > > > This is both the most popular and

Re: [PHP-DEV] [RFC] Arrow functions / short closures

2019-03-13 Thread Rowan Collins
On 13/03/2019 20:37, Chase Peeler wrote: Anyone considered? ($x) => $x * $multiplier I use this format a lot in javascript, so I like not having any indicator. I can't remember which language it was, but they didn't even require the parentheses if there was only a single input: $x => $x *

Re: [PHP-DEV] RFC Draft: Comprehensions

2019-03-13 Thread Stanislav Malyshev
Hi! > I think my main point of feedback would be to stick closer to existing PHP > syntax, even if it costs us some brevity. I would prefer > > $gen = [foreach ($list as $x) if ($x % 2) yield $x * 2]; > > over > > $gen = [for $list as $x if $x % 2 yield $x * 2]; Agree here. There's a

Re: [PHP-DEV] [RFC] Arrow functions / short closures

2019-03-13 Thread Chase Peeler
On Wed, Mar 13, 2019 at 4:26 PM Travis van der Font wrote: > Arrow functions are ternary operators to functions. > While they are nice and shorten, they can be hard to read at times; > considerably to people who aren't used to them which is surprisedly a > majority of PHP programmers. > > Having

Re: [PHP-DEV] [RFC] Arrow functions / short closures

2019-03-13 Thread Travis van der Font
Arrow functions are ternary operators to functions. While they are nice and shorten, they can be hard to read at times; considerably to people who aren't used to them which is surprisedly a majority of PHP programmers. Having them optional sure, but not necessary. Feel free to decide between

Re: [PHP-DEV] Re: [VOTE] RFC: Unbundle ext/wddx

2019-03-13 Thread Christoph M. Becker
On 06.03.2019 at 14:31, Christoph M. Becker wrote: > Still, I'm looking for someone who is willing to create a new home for > ext/wwdx on PECL. Still, I'm looking for someone who is willing to create a new home for ext/wwdx on PECL. -- Christoph M. Becker -- PHP Internals - PHP Runtime

Re: [PHP-DEV] [RFC] Arrow functions / short closures

2019-03-13 Thread Ben Ramsey
> On Mar 13, 2019, at 10:56, Nikita Popov wrote: > > Hi internals, > > Motivated by the recent list comprehensions RFC, I think it's time we took > another look at short closures: > > https://wiki.php.net/rfc/arrow_functions_v2 > > This is based on a previous (withdrawn) proposal by Levi &

[PHP-DEV] [RFC] Arrow functions / short closures

2019-03-13 Thread Nikita Popov
Hi internals, Motivated by the recent list comprehensions RFC, I think it's time we took another look at short closures: https://wiki.php.net/rfc/arrow_functions_v2 This is based on a previous (withdrawn) proposal by Levi & Bob. It uses the syntax fn($x) => $x * $multiplier and implicit

Re: [PHP-DEV] On fixing DOMNameSpaceNode and DOM NS API Inconsistency Problems

2019-03-13 Thread Rob Richards
There were specific reasons for it tho I can't recall all the details off the top of my head. Part of it related to the underlying structures of attributes and namespace nodes not being the same and cannot be user interchangeable in the code, unless only inspected at the nodeptr level. Trying to