Den 2017-05-30 kl. 17:09, skrev Levi Morrison:
Well, my preference would be for alternative 3. Not in favour of 2 & 4.
Nr 1 not so sure about and for nr 5, maybe tweak it to:
- [](params) ==> expr// binds no values
- [=](params) ==> expr// binds by value
- [&](params) ==> expr// bind
> Well, my preference would be for alternative 3. Not in favour of 2 & 4.
> Nr 1 not so sure about and for nr 5, maybe tweak it to:
> - [](params) ==> expr// binds no values
> - [=](params) ==> expr// binds by value
> - [&](params) ==> expr// binds by reference
Can you explain why you
On 30 May 2017 09:30:02 BST, "Björn Larsson" wrote:
>I presume then that the options discussed earlier "|params| => expr"
>and "lamda(params) => expr" are of the table.
I'm a fan of "lambda(params) => expr" myself, because unlike "fn", it makes it
clear that this is a *new type of definition*, n
Den 2017-05-30 kl. 04:48, skrev Levi Morrison:
On Mon, May 29, 2017 at 4:47 AM, Björn Larsson
wrote:
Den 2017-04-05 kl. 23:57, skrev Levi Morrison:
Any plans to go with this for 7.2?
I have been working on this RFC a bit in the last two weeks and intend
to start voting within the next week.
> As a C++ developer, I have no inherent problems with this **in
> theory**, but I agree with your statement that it's a bit symbolic
> soupish. I also suspect that we'll run into grammar ambiguities.
> Imagine: [ []($x) => $x ]. This is current legal syntax (at the
> point of compilation) beca
On Mon, May 29, 2017 at 10:48 PM, Levi Morrison wrote:
> Based on the discussion there are a few different syntax choices that
> we probably just need to vote between. It's a feature that people seem
> to want but everyone seems to prefer a different syntax choice.
>
> 1. fn(params) => expr
>
On Mon, May 29, 2017 at 4:47 AM, Björn Larsson
wrote:
> Den 2017-04-05 kl. 23:57, skrev Levi Morrison:
>
>>> Any plans to go with this for 7.2?
>>
>> I have been working on this RFC a bit in the last two weeks and intend
>> to start voting within the next week.
>
> Any hope this one will make it i
Den 2017-04-05 kl. 23:57, skrev Levi Morrison:
Any plans to go with this for 7.2?
I have been working on this RFC a bit in the last two weeks and intend
to start voting within the next week.
Great, I look forward to reading the updated RFC :) Will you
include both a short- and longhand version
> Any plans to go with this for 7.2?
I have been working on this RFC a bit in the last two weeks and intend
to start voting within the next week.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Den 2017-03-24 kl. 21:08, skrev ilija.tov...@me.com:
Hi Rowan
I see. I still think a simple poll would be useful to choose the least
controversial syntax.
Otherwise I fear that the RFC might get rejected out of superficial reasons.
Regards,
Ilija
On 7 Feb 2017, 21:07 +0100, Rowan Collins ,
Hi Rowan
I see. I still think a simple poll would be useful to choose the least
controversial syntax.
Otherwise I fear that the RFC might get rejected out of superficial reasons.
Regards,
Ilija
On 7 Feb 2017, 21:07 +0100, Rowan Collins , wrote:
> Hi Ilija,
>
> On 7 February 2017 18:58:15 GMT+0
Hi Ilija,
On 7 February 2017 18:58:15 GMT+00:00, ilija.tov...@me.com wrote:
>And also, have you considered letting people vote for their preferred
>arrow function syntax?
>I kinda don’t think we’re gonna find an agreement as there are so many
>different opinions.
The problem with voting on altern
Hey everyone
I’m on team C as well.
One complaint about the RFC is that it doesn’t support multi-statement bodies.
Arrow functions are especially useful for functional programming where it’s
common to return a value in a single expression. Using multiple statements
(partly) destroys the useful
On 30/01/2017 17:55, Levi Morrison wrote:
Here is an example of an existing closure:
function ($x) use ($arr) {
return $arr[$x];
}
This RFC proposes syntax and semantics to simplify this common usage to:
fn($x) => $arr[$x]
I think a lot of the disagreements and confus
I'd strongly prefer a syntax without the introduction of "fn" keyword -
e.g. similar to closures in other languages.
I also feel that there's a feature missing - something that was possible
with closures:
$total = 0;
$add = function ($value) use (&$total) {
$total += $value;
};
Per the RFC:
> I personally don’t see a huge use for this in my own work actually, I’m just
> trying to make sure that something I will likely have to live with from
> *other* developers isn’t impossible to read, that’s all. But I agree that
> most people seem focussed on the actual syntax.
Well, I do. We u
Hi Ilija,
> On 4 Feb 2017, at 23:19, ilija.tov...@me.com wrote:
>
> Hey Stephen
>
>> You’re really starting to lose me now. You want types but don’t want to
>> define them, and you’re somehow mixing phpdoc into this.
>
> Because we use PHPDoc to provide type hints to the IDE where PHP doesn
Hey Stephen
> You’re really starting to lose me now. You want types but don’t want to
> define them, and you’re somehow mixing phpdoc into this.
Because we use PHPDoc to provide type hints to the IDE where PHP doesn’t
support them yet (variables and properties).
> Currently PHP has zero suppor
Hi Ilija,
For some reason I don’t see your original reply yet. Anyway…
> On 4 Feb 2017, at 22:48, ilija.tov...@me.com wrote:
>
> Ah, my example was of course wrong again -.-
>
> The caller should’ve looked like this (although I think you get the point):
>
> ```Swift
> fetchUsers { users in
>
Ah, my example was of course wrong again -.-
The caller should’ve looked like this (although I think you get the point):
```Swift
fetchUsers { users in
// `users` is inferred to be an array of `User`s
}
```
Regards
On 4 Feb 2017, 16:41 +0100, ilija.tov...@me.com, wrote:
> Hey Stephen
>
> >
Hey Stephen
> You don't *have to* specify types at all. If you want to use PHP without
> verifying/requiring types, thats your prerogative, but given the recent
> improvements to allow scalar type hinting, I think it’s a mistake to say that
> *any* use of type hints is “not recommended”.
Sure
Hi Ilija
> On 4 Feb 2017, at 17:09, ilija.tov...@me.com wrote:
>
> Hi Stephen
>
>> Using type hints is a part of the language. It even has benefits that I can
>> absolutely see being used here:
>>
>> array_map(function(Foo $x) => $x->bar());
>>
>> If Foo is a class/interface with a method of
Hi Stephen
> Using type hints is a part of the language. It even has benefits that I can
> absolutely see being used here:
>
> array_map(function(Foo $x) => $x->bar());
>
> If Foo is a class/interface with a method of bar, your IDE can know that it's
> a valid method to call.
>
> That of course
On 4 Feb 2017, at 12:26, Levi Morrison wrote:
>> So we should instead use syntax already used for bit wise OR, and further
>> confuse the situation when the function has no parameters and reusing the
>> logical OR operator. Brilliant.
>
> Excuse me, good sir, but can you tell me what the `&`
> So we should instead use syntax already used for bit wise OR, and further
> confuse the situation when the function has no parameters and reusing the
> logical OR operator. Brilliant.
Excuse me, good sir, but can you tell me what the `&` symbol means? I
thought it meant reference but it's also
Hi Stephen,
> On Feb 3, 2017, at 10:38 PM, Stephen Reay wrote:
>
>
>>
>> I absolutely agree that it's terrible… the point is that types (even
>> potential future union types) can be used with short closures, but it
>> certainly doesn't mean they should be. I don't think confusion with a
>>
Hi Aaron,
Sent from my iPhone
> On 4 Feb 2017, at 10:33, Aaron Piotrowski wrote:
>
>
>> On Feb 3, 2017, at 9:06 PM, Stephen Reay wrote:
>>
>>
>>> On 4 Feb 2017, at 07:25, Aaron Piotrowski wrote:
>>>
>>> $callback = |int|float $x| => $x ** 2;
>>
>> Forget the parser, you're giving my eye
> On Feb 3, 2017, at 9:06 PM, Stephen Reay wrote:
>
>
>> On 4 Feb 2017, at 07:25, Aaron Piotrowski wrote:
>>
>> $callback = |int|float $x| => $x ** 2;
>
> Forget the parser, you're giving my eyes diabetes trying to read that.
I absolutely agree that it's terrible… the point is that types (e
> On 4 Feb 2017, at 07:25, Aaron Piotrowski wrote:
>
> $callback = |int|float $x| => $x ** 2;
Forget the parser, you're giving my eyes diabetes trying to read that.
As has been said before, PHP is relatively verbose compared to other languages.
That makes it slightly more characters to type,
> On Feb 3, 2017, at 2:34 PM, ilija.tov...@me.com wrote:
>
> I like the suggested syntax. The only drawback I see is that it inhibits the
> future addition of union types for closures:
>
> |int | float $x| => $x
>
> Adding parentheses of course resolves the issue but looks a bit awkward:
>
> On Feb 3, 2017, at 11:53 AM, Levi Morrison wrote:
>
> One more thing: I'd like to re-emphasize that the syntax that
> JavaScript uses and the one that HHVM/Hack uses are ambiguous in the
> current class of our grammar. The following will not work unless we
> move to a more powerful grammar and
Just throwing it in here while commuting, so it's a top-post with no
references. Saw it yesterday on reddit (!!! Reddit being useful for once
!!!): $callback = |$x| => $x ** 2;
On 31 Jan 2017 22:44, "Bob Weinand" wrote:
>
> > Am 31.01.2017 um 19:41 schrieb Christoph M. Becker :
> >
> > On 31.01.
> Am 31.01.2017 um 19:41 schrieb Christoph M. Becker :
>
> On 31.01.2017 at 19:16, Michael Morris wrote:
>
>> On Tue, Jan 31, 2017 at 12:29 PM, Larry Garfield
>> wrote:
>>
>>> My question is why there's no mention of HHVM short closures, or the
>>> previous RFC to take that approach. See:
>>>
> Am 31.01.2017 um 21:45 schrieb Andrea Faulds :
>
> Hi Marc,
>
> Marc Bennewitz wrote:
>> - Also I like the "use" keyword you have to define your variables
>>
>>-> Would it be helpful to allow "function () use (*) {}" to inline
>> all available variables?
>
> I did think of that, but it'
On 31.01.2017 at 19:16, Michael Morris wrote:
> On Tue, Jan 31, 2017 at 12:29 PM, Larry Garfield
> wrote:
>
>> My question is why there's no mention of HHVM short closures, or the
>> previous RFC to take that approach. See:
>>
>> https://docs.hhvm.com/hack/lambdas/introduction
>
> For what it'
I guess that should avoid the usage of fn() or function() before arguments
(or then make it optional, but I don't like to give much options).
Some possibilites:
array_map(($x) return $x + 1); // or
array_map(($x) = $x + 1); // or
array_map(($x) => $x + 1); // or
array_map(($x) { $x + 1 });
Then:
On Tue, Jan 31, 2017 at 12:29 PM, Larry Garfield
wrote:
> On 01/31/2017 05:14 AM, Bob Weinand wrote:
>
>>
>>> In the case that regular closures got auto-capture, would a
`use($foo, $bar, $baz)` segment on a closure still be honoured (i.e.
disable auto-capture), and would it have any imp
On 01/31/2017 05:14 AM, Bob Weinand wrote:
In the case that regular closures got auto-capture, would a
`use($foo, $bar, $baz)` segment on a closure still be honoured (i.e.
disable auto-capture), and would it have any impact (positive or
negative) on performance/memory usage? After several years
Hi Levi,
On Tue, Jan 31, 2017 at 8:38 PM, Yasuo Ohgaki wrote:
> On Tue, Jan 31, 2017 at 2:55 AM, Levi Morrison wrote:
>
>> This RFC proposes syntax and semantics to simplify this common usage to:
>>
>> fn($x) => $arr[$x]
>>
>
> Could you explain why fn() cannot be removed like ES2015.
I g
Nicolas Grekas schrieb am Di., 31. Jan.
2017, 13:45:
> >
> > As noted in the RFC, this isn't possible due to ambiguities with array
> > keys and yield expressions with keys.
> >
>
> There are not ambiguities technically, so it is possible if we want to:
>
> $a = [
> $y => 'b',
> ($x) =>
>
> As noted in the RFC, this isn't possible due to ambiguities with array
> keys and yield expressions with keys.
>
There are not ambiguities technically, so it is possible if we want to:
$a = [
$y => 'b',
($x) => $x + 1, // key, value pair
];
$a = [
$y => 'b',
(($x) => $x + 1),
Alain Williams schrieb am Di., 31. Jan. 2017, 13:20:
> On Tue, Jan 31, 2017 at 01:06:25PM +0100, Nicolas Grekas wrote:
> > Or just drop any "fn" or "function" keyword, eg
> >
> > ($x, $y) => foo($x, $y);
> >
> > array_map(($x) => $x + 1);
>
> That has the great advantage of being much as Javascri
2017-01-31 13:20 GMT+01:00 Alain Williams :
> On Tue, Jan 31, 2017 at 01:06:25PM +0100, Nicolas Grekas wrote:
> > Or just drop any "fn" or "function" keyword, eg
> >
> > ($x, $y) => foo($x, $y);
> >
> > array_map(($x) => $x + 1);
>
> That has the great advantage of being much as Javascript does th
On Tue, Jan 31, 2017 at 01:06:25PM +0100, Nicolas Grekas wrote:
> Or just drop any "fn" or "function" keyword, eg
>
> ($x, $y) => foo($x, $y);
>
> array_map(($x) => $x + 1);
That has the great advantage of being much as Javascript does this.
https://developer.mozilla.org/en/docs/Web/JavaScript/
On Tue, Jan 31, 2017 at 9:06 PM, Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> Or just drop any "fn" or "function" keyword, eg
>
> ($x, $y) => foo($x, $y);
>
> array_map(($x) => $x + 1);
>
> ?
>
I like your syntax if it cannot be like ES2015 syntax.
--
Yasuo Ohgaki
yohg...@ohgaki.net
Or just drop any "fn" or "function" keyword, eg
($x, $y) => foo($x, $y);
array_map(($x) => $x + 1);
?
2017-01-31 12:14 GMT+01:00 Bob Weinand :
> Hey,
>
> > Am 31.01.2017 um 11:23 schrieb Michael Wallner :
> >
> > On 31/01/17 05:53, Stephen Reay wrote:
> >> Hi Andrea, All,
> >>
> >>> On 31 Jan 2017, at 08:12, Andrea Faulds wrote:
> >>>
> >>> Is it necessary to introduce a new keyword, fn?
> >>>
>
Hi Levi,
On Tue, Jan 31, 2017 at 2:55 AM, Levi Morrison wrote:
> This RFC proposes syntax and semantics to simplify this common usage to:
>
> fn($x) => $arr[$x]
>
Could you explain why fn() cannot be removed like ES2015.
Rowan's syntax sounds attractive to me if fn() cannot be removed.
fn(
Hey,
> Am 31.01.2017 um 11:23 schrieb Michael Wallner :
>
> On 31/01/17 05:53, Stephen Reay wrote:
>> Hi Andrea, All,
>>
>>> On 31 Jan 2017, at 08:12, Andrea Faulds wrote:
>>>
>>> Is it necessary to introduce a new keyword, fn?
>>>
>>> I think you'd get a similar benefit from:
>>>
>>> func
I agree. Using the prefix `function` kind of defeats the purpose of the whole
RFC.
There are three things that contribute to the boilerplate of closures:
- The `function` keyword
- The `return` keyword
- The `use` clause
The RFC eliminates two and reduces one to about 25%.
I also disl
On Mon, 30 Jan 2017 20:55:07 +0300, Levi Morrison wrote:
Bob Weinand and I are happy to announce that the [Arrow Functions][1]
RFC is moving into the public discussion phase. We have been
collaborating on this RFC for many months now and finally have a
proposal we are happy to discuss in the op
On Mon, Jan 30, 2017 at 4:05 PM, Rowan Collins wrote:
> On 30/01/2017 17:55, Levi Morrison wrote:
>>
>> Bob Weinand and I are happy to announce that the [Arrow Functions][1]
>> RFC is moving into the public discussion phase. We have been
>> collaborating on this RFC for many months now and finally
On 30/01/2017 17:55, Levi Morrison wrote:
Bob Weinand and I are happy to announce that the [Arrow Functions][1]
RFC is moving into the public discussion phase. We have been
collaborating on this RFC for many months now and finally have a
proposal we are happy to discuss in the open.
[1]: http
On Tue, Jan 31, 2017 at 7:42 AM, Niklas Keller wrote:
> Levi Morrison schrieb am Mo., 30. Jan. 2017, 18:55:
>
> > Bob Weinand and I are happy to announce that the [Arrow Functions][1]
> > RFC is moving into the public discussion phase. We have been
> > collaborating on this RFC for many months n
Levi Morrison schrieb am Mo., 30. Jan. 2017, 18:55:
> Bob Weinand and I are happy to announce that the [Arrow Functions][1]
> RFC is moving into the public discussion phase. We have been
> collaborating on this RFC for many months now and finally have a
> proposal we are happy to discuss in the o
Bob Weinand and I are happy to announce that the [Arrow Functions][1]
RFC is moving into the public discussion phase. We have been
collaborating on this RFC for many months now and finally have a
proposal we are happy to discuss in the open.
Here is an example of an existing closure:
function
56 matches
Mail list logo
