Sara Golemon wrote:
> looks a bit... ugly? weird? surprising?
I had the same initial reaction, and was going to tell David what I
thought of the suggestion. But after a couple of days, I was unable to
actually articulate what I didn't like it, so think I was just having
a gut reaction to something
> No we can't, try it (Parse error). The correct order is
> "function() use($x): Type".
Oh! You are right!
In this case, we still have the old idea:
function() as $lambda use ($x): int {}
> Ugh. That's ugly. I want to say we should fix it, but the horse has left
the stables, so it's too late to
On Fri, Nov 20, 2020 at 12:58 PM Guilliam Xavier
wrote:
> > I don't know if that would be a problem, because today we can have it
> > "function(): Type use($x)", so "Type use($x)"?
> >
>
> No we can't, try it (Parse error). The correct order is
> "function() use($x): Type".
>
>
Ugh. That's ugly.
On Fri, Nov 20, 2020 at 5:02 PM David Rodrigues
wrote:
> > Is it `returnType as $thing` ? That doesn't read well, but I don't see
> us making return type movable. as/use should be placable in either order,
> but maybe we give them required order anyway?
>
> I don't know if that would be a probl
On Fri, Nov 20, 2020 at 11:40 AM Larry Garfield
wrote:
> > (5) function $lambda(... $args): returnType use ($captures...) {}
> >
> > To be honest, as I typed what came to mind, I ended up preferring this
> last
> > option.
>
> I kind of like that option, too.
Agreed that this has some attractiv
On Fri, Nov 20, 2020, at 10:01 AM, David Rodrigues wrote:
> > Is it `returnType as $thing` ? That doesn't read well, but I don't see
>> us making return type movable. as/use should be placable in either order,
>> but maybe we give them required order anyway?
>
> I don't know if that would be a p
> Is it `returnType as $thing` ? That doesn't read well, but I don't see
us making return type movable. as/use should be placable in either order,
but maybe we give them required order anyway?
I don't know if that would be a problem, because today we can have it
"function(): Type use($x)", so "T
On Wed, Nov 11, 2020 at 12:37 PM David Rodrigues
wrote:
> My suggestion is to reuse the keyword `as` to set a variable that will
> represent its own closure. It is more flexible once that we could choose
> any name and reuse in nested closures. It is pretty similar to how SQL
> works too.
>
> fun
On Wed, 11 Nov 2020 at 18:37, David Rodrigues wrote:
>
> My suggestion is to reuse the keyword `as` to set a variable that will
> represent its own
> closure. It is more flexible once that we could choose any name and reuse in
> nested closures.
> It is pretty similar to how SQL works too.
Hi D
if i have understood the "as"-suggestion correctly:
$fn = function() as $lambdaOrAnyName {var_dump($lambdaOrAnyName);};
(function() as $lambdaOrAnyName{var_dump($lambdaOrAnyName);})();
then that syntax is fine with me. this is also very close to how it
works in JavaScript (except the "as" part),
Hi everyone,
maybe a bad idea, but what about addressing the "Principle of least
astonishment" issue by allowing to specify/capture the variable after
the function is assigned:
$f = function () use ($f) {...};
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Vo
On 11/11/2020 17:59, Christoph M. Becker wrote:
In JavaScript, a named function expression is different to a function
declaration:
var fn = function foo() {console.log('blah')}
foo()
=> Uncaught ReferenceError: foo is not defined
vs.
function foo() {console.log('blah')}
I think that introducing a new variable, that even uncommon, could cause BC.
My suggestion is to reuse the keyword `as` to set a variable that will
represent its own closure. It is more flexible once that we could choose
any name and reuse in nested closures. It is pretty similar to how SQL
works
On 11.11.2020 at 18:39, Dan Ackroyd wrote:
> On Tue, 10 Nov 2020 at 17:39, Hans Henrik Bergan wrote:
>>
>> something i'm missing from Javascript is the ability to give names to
>> closures, ...the name is optional, and only visible inside the closure
>> itself, and unfortunately this is not legal
On Tue, 10 Nov 2020 at 17:39, Hans Henrik Bergan wrote:
>
> something i'm missing from Javascript is the ability to give names to
> closures, ...the name is optional, and only visible inside the closure
> itself, and unfortunately this is not legal in PHP, i wish it was.
I really like that...but
Think the way it is implemented in JS is better than `$lambda` variable. At
least it doesn't have BC breaks (does it?)
On Tue, Nov 10, 2020, 7:38 PM Hans Henrik Bergan
wrote:
> something i'm missing from Javascript is the ability to give names to
> closures,
> this both gives closures the abilit
something i'm missing from Javascript is the ability to give names to closures,
this both gives closures the ability to reference themselves, but it
also makes for meaningful stack traces, eg this is legal javascript:
(function TheClosuresLocalName(){console.log(TheClosuresLocalName);
throw new Er
On Tue, Nov 10, 2020 at 10:09 AM Dan Ackroyd wrote:
>
> Hello internals,
>
> For reasons, I was reviewing the conversation where adding closures to
> PHP was added, and it reminded me that currently the only way for a
> closure to call itself is slightly terribly, so I drafted an RFC:
>
> https://
Hello internals,
For reasons, I was reviewing the conversation where adding closures to
PHP was added, and it reminded me that currently the only way for a
closure to call itself is slightly terribly, so I drafted an RFC:
https://wiki.php.net/rfc/closure_self_reference
Before I spend time on it,
19 matches
Mail list logo
