[PHP-DEV][RFC][VOTE] Explicit octal integer literal notation
Greetings Internals, The vote for the "Explicit octal integer literal notation" RFC is now open. https://wiki.php.net/rfc/explicit_octal_notation It will last two [2] weeks, until 2020-11-25. Best regards, George P. Banyard
[PHP-DEV] Supports to ?:= assignment operator
Hello! PHP currently supports ??= assignment, as shortly to $a = $a ?? null, but it does not supports ?:= as shortly to $a = $a ?: null. There are some reason to that? - https://wiki.php.net/rfc/null_coalesce_equal_operator - https://wiki.php.net/rfc/short_ternary_equal_operator Thanks! Atenciosamente, David Rodrigues
[PHP-DEV] Re: Supports to ?:= assignment operator
Hi, Den 2020-11-11 kl. 17:18, skrev David Rodrigues: Hello! PHP currently supports ??= assignment, as shortly to $a = $a ?? null, but it does not supports ?:= as shortly to $a = $a ?: null. There are some reason to that? - https://wiki.php.net/rfc/null_coalesce_equal_operator - https://wiki.php.net/rfc/short_ternary_equal_operator Thanks! Atenciosamente, David Rodrigues Work on this was done by Sara Golemon during 2016. I recall that the voting was closed, see: - https://externals.io/message/91901 Maybe time to bring it forward again for PHP 8.1? r//Björn Larsson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Draft - Closure self reference
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 unfortunately that wouldn't work in PHP.
In JS, when a function is declared inside another function, the name
of it is limited to the scope of the containing function. In PHP, when
a function is declared inside another function, it is put into the
current namespace's global scope.
Changing how scope works in PHP would be too large a change for just this.
Levi Morrison wrote:
> Is there any way we can spell it `__FUNCTION__`?
I think using some sort of constant, rather than a magic variable
sounds is probably the way to go. I would hope we could find something
better than that as:
return __FUNCTION__($n-1) + __FUNCTION__($n-2);
is pretty hard on my eyes.
I think I'll wander over to the 'Support for ::function syntax' thread...
cheers
Dan
Ack
# PHP
function foo1() {
function bar() {}
}
function foo2() {
function bar() {}
}
foo1();
foo2();
// Fatal error: Cannot redeclare bar()
# JS
function foo1() {
var fn = function TheClosuresLocalName(){
console.log("I am closure inside foo1");
}
return fn;
}
function foo2() {
var fn = function TheClosuresLocalName(){
console.log("I am closure inside foo2");
}
return fn;
}
fn1 = foo1();
fn2 = foo2();
fn1();
fn2();
"I am closure inside foo1"
"I am closure inside foo2"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Draft - Closure self reference
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 in PHP, i wish it was.
>
> I really like that...but unfortunately that wouldn't work in PHP.
>
> In JS, when a function is declared inside another function, the name
> of it is limited to the scope of the containing function. In PHP, when
> a function is declared inside another function, it is put into the
> current namespace's global scope.
>
> Changing how scope works in PHP would be too large a change for just this.
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')}
foo()
=> blah
So the named function expression is still an anonymous function; the
label is only defined inside of the function body.
Christoph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Draft - Closure self reference
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 too.
function fn1() as $lambda1 {
return function() as $lambda2 use ($lambda1) {
return [ gettype($lambda1), gettype($lambda2) ];
};
}
Atenciosamente,
David Rodrigues
Em qua., 11 de nov. de 2020 às 14:59, Christoph M. Becker
escreveu:
> 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 in PHP, i wish it was.
> >
> > I really like that...but unfortunately that wouldn't work in PHP.
> >
> > In JS, when a function is declared inside another function, the name
> > of it is limited to the scope of the containing function. In PHP, when
> > a function is declared inside another function, it is put into the
> > current namespace's global scope.
> >
> > Changing how scope works in PHP would be too large a change for just
> this.
>
> 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')}
> foo()
> => blah
>
> So the named function expression is still an anonymous function; the
> label is only defined inside of the function body.
>
> Christoph
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC] Draft - Closure self reference
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')}
foo()
=> blah
So the named function expression is still an anonymous function; the
label is only defined inside of the function body.
I think the key difference is that in JS, functions and variables occupy
the same namespace, so "function foo" and "var foo = function" mean
roughly the same thing. For the same reason, *inside* a named function
expression, it acts as though there is a local variable with the given name:
var fn = function foo() {console.log(typeof foo)};
fn();
// outputs 'function'
which actually makes it very similar to...
On 11/11/2020 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.
function fn1() as $lambda1 {
return function() as $lambda2 use ($lambda1) {
return [ gettype($lambda1), gettype($lambda2) ];
};
}
I like this idea; it avoids reserving a magic variable name, but gives
all the flexibility of having the full Closure object available (having
a "constant" whose value was a Closure object would be somewhat odd).
To take Dan's example from the RFC, this would no longer have any surprises:
$fibonacci = function (int $n) as $fibonacci {
if ($n === 0) return 0;
if ($n === 1) return 1;
return $fibonacci($n-1) + $fibonacci($n-2);
};
$this_is_the_original_fibonacci = $fibonacci;
$fibonacci = function (int $n) { return rand(0, $n); };
echo $this_is_the_original_fibonacci(10). "\n";
The $fibonacci inside the closure would be a normal local variable,
which just happens to have the same name as the one outside, so
assigning to one would have no effect on the other.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Draft - Closure self reference
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říšek
On 10 Nov 2020 18:08, 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://wiki.php.net/rfc/closure_self_reference
Before I spend time on it, is there any strong reason why this is a bad idea?
cheers
Dan
Ack
Re: [PHP-DEV] [RFC] Draft - Closure self reference
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),
i like the as-suggestion better than the $lambda suggestion in current
RFC-draft,
it has 0 bc break and people who want to call it $lambda can simply do
function() as $lamda{};
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] strict_types will be default at some moment?
Hello! I have been asked by a friend if declare(strict_types=1) will be applied by default for some version of PHP, like 9.x or will it be always required by all scripts forever. Someone can tell me? If yes, what is the reason for requiring it? Why it can't be the default behavior (or maybe, the unique behavior). Atenciosamente, David Rodrigues
Re: [PHP-DEV] strict_types will be default at some moment?
> Le 11 nov. 2020 à 21:20, David Rodrigues a écrit : > > Why it can't be the default > behavior (or maybe, the unique behavior). IMNSHO, a good reason for keeping weak typing, is that developers are not willing to review and refactor megabytes of valid code that take advantage of implicit type conversion. —Claude -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] strict_types will be default at some moment?
On 11/11/2020 20:20, David Rodrigues wrote: I have been asked by a friend if declare(strict_types=1) will be applied by default for some version of PHP, like 9.x or will it be always required by all scripts forever. Someone can tell me? If yes, what is the reason for requiring it? Why it can't be the default behavior (or maybe, the unique behavior). The question (which I hear often) misunderstands the original intent of the declaration, as I understand it: the strict_types switch was not designed as a transition mechanism for old code, it was designed as a genuine choice between two different options, both equally new. Before PHP 7.0, there was no ability for a (user-defined) function to declare that it wanted an int, string, float, or boolean argument. When it was proposed that these "scalar type hints" be added, there were different, strongly held, opinions on how that should work, leading to at least 5 separate RFCs, several thousand mailing list posts, and a lot of general unhappiness. The idea behind the strict_types directive was to combine two versions of the feature into one system, allowing users to switch between them at will. The proposal made clear that both modes have their advantages and disadvantages. A few of those were affected by compatibility with older code - in particular, around the behaviour of built-in functions - but those were not the main driving factors behind providing two modes. Perhaps, 5 or 6 years on, things have changed. Certainly, there are a vocal community of users who see "strict_types=1" as unreservedly "better" in some fundamental way - but then, there always were, that's why the debate was so heated. I rather suspect that most of the arguments put forward for one position or the other then are just as true now. I do wonder if people would even be asking the question, if the modes had been named something like "scalar_types=coerce" and "scalar_types=error", and somehow arranged such that neither was in force by default. [PS: What a beautifully timed e-mail - "11/11/2020 20:20 UTC"!] Regards, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] strict_types will be default at some moment?
On Wed, 11 Nov 2020 at 21:47, Rowan Tommins wrote: > On 11/11/2020 20:20, David Rodrigues wrote: > > I have been asked by a friend if declare(strict_types=1) will be applied > by > > default for some version of PHP, like 9.x or will it be always required > by > > all scripts forever. Someone can tell me? > > > > If yes, what is the reason for requiring it? Why it can't be the default > > behavior (or maybe, the unique behavior). > > > The question (which I hear often) misunderstands the original intent of > the declaration, as I understand it: the strict_types switch was not > designed as a transition mechanism for old code, it was designed as a > genuine choice between two different options, both equally new. > > Before PHP 7.0, there was no ability for a (user-defined) function to > declare that it wanted an int, string, float, or boolean argument. When > it was proposed that these "scalar type hints" be added, there were > different, strongly held, opinions on how that should work, leading to > at least 5 separate RFCs, several thousand mailing list posts, and a lot > of general unhappiness. > > The idea behind the strict_types directive was to combine two versions > of the feature into one system, allowing users to switch between them at > will. The proposal made clear that both modes have their advantages and > disadvantages. A few of those were affected by compatibility with older > code - in particular, around the behaviour of built-in functions - but > those were not the main driving factors behind providing two modes. > > Perhaps, 5 or 6 years on, things have changed. Certainly, there are a > vocal community of users who see "strict_types=1" as unreservedly > "better" in some fundamental way - but then, there always were, that's > why the debate was so heated. I rather suspect that most of the > arguments put forward for one position or the other then are just as > true now. > > I do wonder if people would even be asking the question, if the modes > had been named something like "scalar_types=coerce" and > "scalar_types=error", and somehow arranged such that neither was in > force by default. > > > [PS: What a beautifully timed e-mail - "11/11/2020 20:20 UTC"!] > > > Regards, > > -- > Rowan Tommins (né Collins) > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > As Rowan pointed out strict_types have a complicated history, and to some extent were a bandage fix, a very good one which might have been *too* good. Let me try to explain by looking at how strict_types circumvented some of the nonsensical coercive mode behaviour. (Reminding that this is in PHP 5 days) 1. Preventing float to integer conversion, which could lead to a loss of data if a fractional part exists 2. Preventing integers, floats, and strings to pass a boolean type declaration 3. Preventing booleans to pass an integer, float, or string type declaration 4. Preventing internal functions from coercing null to the corresponding scalar type 5. Preventing strings which look numeric (i.e. leading-numeric strings) to pass integer/float checks It should be noted that all of these issues exist (in "weak" typing mode) in PHP 7 and only the last item of the previous list has been "fixed" in PHP 8.0, with the "Stricter Numeric Strings" RFC. [1] The "competing" RFC to strict_type scalar type declarations "Coercive Types for Function Arguments" [2] made provisions to some of these cases, namely 1, 3, and 5. However, they were made as deprecation notices, which until PHP 8.0, were silenced by default. Case 4 might finally be solved as in PHP 8.0 a lot of work went towards making internal functions accept null (or have a reasonable default value) for optional arguments. For case 2 one can argue both ways that it makes sense that non boolean values resolve to true or false to pass a type declaration. Now going back to strict_types being *too* good of a bandage fix is that none of the above issues have been addressed during the PHP 7 release cycle which could have made coercive typing less surprising (the float to integer being the most surprising IMHO) by introducing warnings/deprecation notices and making them TypeErrors in PHP 8. As such I think, it would be better to improve coercive typing during this major release cycle by making it stricter and more akin to strict_type semantics such that the strict_type declare statement might become "obsolete" in PHP 9. Best regards, George P. Banyard [1] https://wiki.php.net/rfc/saner-numeric-strings [2] https://wiki.php.net/rfc/coercive_sth
[PHP-DEV] Re: strict_types will be default at some moment?
On 11/11/2020 20:20, David Rodrigues wrote: If yes, what is the reason for requiring it? Why it can't be the default behavior (or maybe, the unique behavior). There was some discussion around the idea of adding language editions to PHP for 8.0, however the pandemic resulted in to the in-person conference that would have discussed it being cancelled. If that ever goes back into discussion, I think that I and many others would argue that strict_types=1 would be a baseline requirement of the first edition. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
