On 06.10.20 17:15, Sara Golemon wrote:
My opinion on constructor property promotion (CPP) is that it's something
for small value object classes and should probably be regarded as
code-smell on larger classes. At the same time, annotations belong with
more complex objects and not so much with
On 05.10.20 12:15, Deleu wrote:
To me that seems like a great argument in favour of the proposal. If you'll
want all variables to be imported (which in this case makes completely
sense), then `fn() {}` or `fn() => {}` is much less verbose and inline with
the mentality to reach for short
On 05.10.20 12:08, Lynn wrote:
How should php deal with the scenario where you want to `use` everything
and have one variable by reference?
```
function () use (*, &$butNotThisOne) {};
```
The easiest would be to only allow "use (*)" with no references or
additional syntax. "use (*)" would
On 04.10.20 22:08, Rowan Tommins wrote:
If we added an opt-in syntax for "capture everything", we might
instead write this:
$f = function() use (*) {
$x = $y = $z = null;
}
Without re-initialising all local variables, we would no longer be
able to know if they were actually local without
On 18.08.20 00:03, Benas IML wrote:
And then boo-yah, 6 months later we want to implement a cool new
feature to
attributes (a lot of examples were said before, ain't repeating myself) but
we can't :(( because there is no ending delimiter and thus, we will run
into parsing issues.
Both @{} and
On 19.08.20 10:47, Benjamin Eberlei wrote:
One last change that I didn't see yesterday as it was on Github and not
this list is the addition of another syntax proposal @{} with the same
benefits as @[], a little more snowflake than compared to other languages,
but without the BC Break.
I
On 19.08.20 11:12, Benjamin Eberlei wrote:
With the choice being @@ or @{} - nothing would stop someone (not me ;-))
to make an RFC for 8.1 or later proposing to add a second syntax.
Sure. If @@ would end up winning again (who knows at this point), at
least one positive thing is that @{} could
As a possible addition/discussion point, I only noticed today that @{}
is a syntax that has not been mentioned yet, also not in any previous
discussions about attributes as far as I can tell. @{} currently leads
to a syntax error, so there is no BC break, and {} is common syntax for
grouping
On 15.08.20 11:54, Michał Marcin Brzuchalski wrote:
I don't think there's anything significant changed in the RFC. I really
doubt the vote result will change significantly.
Currently you're the only one who wants to wipe the vote and there is no
much voices willing to follow your proposal.
On 15.08.20 12:35, Michał Marcin Brzuchalski wrote:
If you wanna follow democratic rules then first of all 4 is not a quorum.
Secondly, you should be fine with additional voting about stopping current
RFC vote, right?
The RFC process has been agreed upon by the people involved with PHP. It
On 10.08.20 15:05, Markus Fischer wrote:
Personally, and never gave it much thought TBH, the `@@` AND `<<`/`>>`
in fact is the most "unreadable" version to me because duplicate
occurrence of a single character somehow creates a noise _for me_,
I don't feel eligible to have a vote, but based on
On 10.08.20 15:08, Benjamin Eberlei wrote:
() does not count as ending symbol, because it is not required, as
such its
not an ending symbol.
The point Andreas Leathley makes in the discussion thread about new Foo not
having an end symbol demonstrates exactly the opposite point he was trying
On 11.08.20 18:38, Sara Golemon wrote:
The perf penalty on 7 and earlier would probably be similar to existing
state of the world.
Parsing a docblock is easier to fetch from the runtime (as we actually
store it), but docblocks contain more than just annotations, so some plus
some minus.
PHP 8+
On 10.08.20 17:40, Derick Rethans wrote:
It missing an ending delimiter was my first reason for wanting to get
something better than @@. I don't particularly care much if it ends up
being @[], #[], <<>>, or other things such as @:( ).
If you have something to open, and close, there there is a
On 12.08.20 17:25, Sara Golemon wrote:
Changing the syntax isn't a feature. It's a refinement. One of the things
our long release process provides is a chance to be absolutely certain
before we introduce syntax we'll come to regret later.
The current RFC does not discuss the BC breaks of each
Hello Derick & Internals,
I am a daily user of PHP and read through all the recent discussions about the
attribute syntax, and thought I could add some slightly different viewpoints
from an "end-user" who uses the current annotations a lot. This is my first time
posting, so I am hoping I am doing
On 13.08.20 15:17, Theodore Brown wrote:
The discussion thread you're referencing did not announce an RFC. Per
the voting rules, a "Proposal is formally initiated by creating an
RFC on PHP wiki and announcing it on the list". After that there must
be a minimum two week discussion period before
On 11.08.20 15:15, Lynn wrote:
If typability really matters, we should've deprecated the backtick
version
to run things. We also seem to forget about readability. @@ makes things
really hard to read for me as it draws attention, the same goes for <>
being written as such, with spaces it's fine.
On 11.08.20 18:07, Sara Golemon wrote:
Writing this on PHP 7 (or any earlier version for that matter) would be
valid syntax (ignored as a comment):
#[SomeAttr(123)]
function someFunc() {}
That's what's meant by Forward Compatibility. Library/Framework authors
could aggressively adopt
On 16.08.20 01:07, Paul M. Jones wrote:
/me furrows brow
If I understand correctly, that means the currently-running vote overlaps with
the discussion period? If so, that sounds (again) highly irregular.
The proper thing to do here is a full reset: restart the 2-week discussion
period at the
On 14.08.20 03:41, Levi Morrison via internals wrote:
I just want to make sure I understand: there are people who think we
haven't discussed the syntax for attributes yet?
I assume this is a serious email, but I can't fathom why anyone cares.
We've discussed this subject soo much...
I am kind
On 11.12.20 10:59, Máté Kocsis wrote:
That's why I'd like to add support for measuring the execution timeout
based on the wall-time. There are a couple of ways to approach the problem
though:
- by measuring wall-time on all platforms
- by adding a new "max_execution_time_type" or so ini setting
On 15.12.20 20:08, Sara Golemon wrote:
Or even better with existing syntax:
```php
$this->handler = match($var) {
null, true, false => json_encode($var),
default => \is_string($var) ? "\"$var\"" : \rtrim(\print_r($var, true)),
};
I appreciate that this is a specific counter-example to
I checked in my vendor directory for currently used switch(true) usages,
there were 96 matches. It is often used when handling an unknown value
and needing to display or convert it, as there the structure of a switch
is easier to scan compared to other comparisons like ifs (at least it is
for
On 14.12.20 18:33, Larry Garfield wrote:
I present to Internals this tiny RFC to follow up on the match() expression RFC
from earlier in the year. There was solidly positive support for this shortcut
previously but it was removed for simplicity at the time, with the intent to
bring it back
On 12.01.21 17:51, Marco Pivetta wrote:
Code written to deal with `array` in a generic way will no longer work
when
invoked through code paths that produce object keys: this is a general
problem with widening types overall, and is a clear BC break.
If you look at levels of BC break, this is on
On 18.06.21 08:00, Craig Francis wrote:
As there’s been no issues raised with supporting integers, and doing so
will help adoption, the implementation will be updated to allow them.
Now to choose the name, with the options is_known() from Joe and
is_trusted() from Moritz:
On 24.06.21 13:17, Kamil Tekiela wrote:
I am against adding these functions, but for different reasons than Sara
and George.
If we add str_left and str_right then there should be a corresponding
variant in mbstring. The byte-string functions are rarely useful. Adding
these functions to mbstring
On 20.05.21 21:35, Larry Garfield wrote:
There's been a lot of rapid iteration, experimentation, and rejection.
The most recent alternatives are this one from Levi:
https://gist.github.com/morrisonlevi/f7cf949c02f5b9653048e9c52dd3cbfd
And this one from me:
On 26.05.21 12:13, Joe Watkins wrote:
Not absolutely convinced that it's a good idea, I asked Nikita to review,
and he's unconvinced also and suggested a discussion should be started.
You can read both of our thoughts about it on the PR.
What I'm looking for now, is reasons that we are wrong -
On 27.05.21 16:43, Rowan Tommins wrote:
isset in this case is abused to check for uninitialized, hiding the
actual intent
On the contrary, the uninitialized state is what is being abused. If
you want to make the intent clear, use a clear flag of "needs
lazy-loading", or whatever you're
On 27.03.21 17:05, Rowan Tommins wrote:
My biggest concern with automatic capture is the potential for
*accidentally* capturing variables - that is, intending to introduce a
local variable inside the closure, but capturing a variable from the
outer scope that happens to have the same name. This
On 01.04.21 10:56, Benjamin Eberlei wrote:
This RFC is using the declaration of the return type, to specify that it
never returns. As such noreturn or never is a keyword a long the lines of
public or final, but it is not a return type.
I don't think the argument for potential optimizations in
On 01.04.21 17:07, Benjamin Eberlei wrote:
I don't know, you are arguing that you forgot a return, but you also did
not forget to add a never return type. You
could easily fix this by inlining the exception instead.
```php
if (!isset($user)) {
throw new NotFoundException();
}
```
Even when
On 03.04.21 18:30, Benjamin Eberlei wrote:
if (is_string($value) && is_int($value)) {
// inside here $value is_type == "never"
}
The naming "never" here makes no sense, because from a theoretical
perspective reasoning about the type of $value it is nothing and only the
block of code is
On 03.04.21 21:26, Peter Bowyer wrote:
This and Levi's email make compelling arguments and I would like to see
this adopted. I have changed my vote to "No".
Wasn't Levi arguing for the RFC? Introducing "never" as a bottom type is
what Levi was strongly arguing for, and that is what the RFC
On 04.03.21 14:07, G. P. B. wrote:
This new version of the RFC can be found on the wiki: [2]
https://wiki.php.net/rfc/implicit-float-int-deprecate
I like the RFC, but I think the diagnostic messages will be hard to
understand when they come up in real scripts, especially because they
can be
On 21.04.21 15:14, Christian Schneider wrote:
I never really understood the desire to restrict how people can use
your code.
If there is no good reason to override the value of a class constant people
won't do it.
If there might be a good reason (even one you as the original designer didn't
On 25.08.21 12:45, Rowan Tommins wrote:
* Adding a parent to an existing class isn't always possible, if it
already inherits from something else. Perhaps the behaviour could also
be available as a trait, which defined stub __get and __set methods,
allowing for the replacement of the internal
On 05.01.22 10:42, Jordan LeDoux wrote:
I suppose the alternative would be to withdraw the RFC
now that a wider variety of voters are providing feedback than the other
three threads.
I would let the vote go on, as there are still many voters who have not
voted on this yet, giving the proposal
On 03.01.22 17:12, Larry Garfield wrote:
Also, people keep talking about edge cases. In my experience, "are
these two objects equal" (for some object-specific definition of
equal) is very much *not* an edge case. I may have less use for
overloading % as I don't use advanced math that much, but I
On 02.01.22 00:17, Craig Francis wrote:
I've spent a few days coming up with a short(ish) list of parameters that
are likely to receive `NULL`.
The focus is on making it easier for developers to upgrade to newer
versions of PHP. I'm thinking of the typical developer, probably using
WordPress,
On 15.11.21 10:47, Derick Rethans wrote:
GitHub is a proprietary platform, where unlike with the code
repositories, the interactions and issues are not easy to migrate out of
again. It is also now owned by MSFT, and although they are making
friendly noises towards Open Source, I remain largely
On 19.07.21 11:21, azjezz wrote:
however, when `T` is an intersection between `X` and `T` ( `X` ), `X $x = null` becomes
`null|X $x = null`, which is a combination between union and intersection types, however, as
the RFC stats, currently combination between union and intersection types is not
On 16.07.21 09:06, Nikita Popov wrote:
We cannot make properties readonly by default, because that would be a
major backwards compatibility break.
If you're going for brevity, something you can do is omit the visibility
specifier, as it is public by default. "readonly int $prop" works.
Would
On 23.07.21 11:58, Nicolas Grekas wrote:
Hi everyone,
as proposed by Nikita and Joe, I'm submitting this late RFC for your
consideration for inclusion in PHP 8.1. Intersection types as currently
accepted are not nullable. This RFC proposes to make them so.
I wrote everything down about the
On 15.02.22 13:31, Nicolas BADIA wrote:
As it is explained in this ticket https://bugs.php.net/bug.php?id=81417 we use
to check if a property exists by accessing it directly like we do in JavaScript.
Personally, I subscribe to this coding style and we use it all over our
codebase (more than
On 02.03.22 15:00, Craig Francis wrote:
On Wed, 2 Mar 2022 at 12:26, Dik Takken wrote:
So, to get this crystal clear, this is my understanding of what you are
proposing for passing null to a non-nullable function parameter
(hopefully my ASCII art will come through ok):
which |
On 02.03.22 15:27, Craig Francis wrote:
On Wed, 2 Mar 2022 at 14:17, Larry Garfield wrote:
Null is not an empty string. Null is not a string. Null is not 0. Null
is not an integer.
So what should this do?
$name = ($_POST['name'] ?? NULL);
var_dump($name == '');
Is that now going to be
On 02.03.22 16:00, Craig Francis wrote:
I'll note that converting from NULL is used all the time, and is well
defined:
https://www.php.net/manual/en/language.types.string.php
"null is always converted to an empty string."
https://www.php.net/manual/en/language.types.integer.php
"null is
On 11.04.22 20:22, Craig Francis wrote:
Just take NULL to String coercion as an example, the documentation
clearly
and simply says “null is always converted to an empty string”, this needs
to be updated to end with "... except when being passed to a function, in
which case NULL will result in a
On 14.04.22 10:10, Craig Francis wrote:
My intro says "Roughly 85% scripts do not use strict_types=1", and "Roughly
33% of developers use static analysis" (source of numbers noted in my
RFC)... while that does not guarantee anything, it's a fairly good
indication that most developers do not
There is another 3.5 years until PHP 9 is likely to come out, which is a
lot of time for people to adjust their codebase. I could even see an
argument for not promoting it to a fatal error in 9.0 if so many people
need more time.
If it's deprecated, that is an intent to break... and if no
On 14.04.22 14:14, Craig Francis wrote:
Yep, I agree with everything you have said there, and it's what George
seems to be working towards (which I also agree with):
https://github.com/Girgias/unify-typing-modes-rfc
Yet your RFC goes exactly against the quoted document by making the
be to make these
probably-not-boolean usages more visible in codebases. Depending on the
feedback here I would create an RFC and try to do an implementation (to
then discuss it in more detail), so as of now this is mostly about
getting some basic feedback on such a change, and if someone else has
had any similar thoughts/plans.
Thanks for any feedback!
Andreas Leathley
On 26.04.22 12:02, Mark Randall wrote:
On 26/04/2022 10:54, Andreas Leathley wrote:
Any non-empty string (except "0") is converted to true and any non-zero
integer or float is converted to true.
If we could get rid of "0" being false, that alone would be a huge
bene
On 26.04.22 14:47, Christian Schneider wrote:
There are two big reasons:
- BC: Checking for the truthiness of a value is very common and would require a
lot of code changes.
- Some of us like the conciseness of "if ($foo) ...", see below
That would not be my target - in an if expression a lot
On 26.04.22 15:27, Rowan Tommins wrote:
I was actually thinking about this the other day, in the context of
adding new cast functions which reject more values than our current
explicit casts.
This is also something I am interested in - having functions which do
the same as implicit type
On 10.11.23 12:33, Craig Francis wrote:
On 10 Nov 2023, at 10:54, Alex Wells wrote:
PHPStan does find
them:https://phpstan.org/r/38fc1545-2567-49b9-9937-f275dcfff6f5
It does not:
https://phpstan.org/r/c533ff42-80e4-4309-9751-1ec79e359946
Psalm does give you a PossiblyInvalidArgument
On 17.05.22 11:18, Jordi Boggiano wrote:
Thanks for the RFC. I think it's overall a good idea, especially for
cases like "false" => true, and arguably for ints >1/<0, but my gut
feeling is the string=>bool deprecation will lead to a lot of pain.
I definitely see this being done in many places
Hello Internals,
I would like to request wiki edit privileges to prepare an RFC for
Stricter implicit boolean coercions, where I started a discussion
recently and am currently finalizing an preliminary implementation.
Username: iquito
Thanks!
Best regards,
Andreas Leathley
I have amended the RFC on
https://wiki.php.net/rfc/stricter_implicit_boolean_coercions to address
the feedback I got so far, I also added an overview of scalar type
coercions to give a better sense of how these changes fit in with
current type coercion behavior, and I added a Future Scope section
On 23.05.22 20:58, Juliette Reinders Folmer wrote:
This RFC worries me as, in my opinion, it makes PHP's behaviour more
surprising and inconsistent, not less.
It also raises the cognitive complexity for developers by yet another
level.
1. It introduces a new interpretation of boolean type
On 23.05.22 22:54, G. P. B. wrote:
I don't like this RFC as it introduces special coercion semantics for
boolean *only* in a function (+ typed properties (well at least I hope it
impacts typed properties)) context.
The obvious other context is the logical one with conditional statements
and/or
Hello Kamil,
I suspect this is very different depending on the codebase. My main
reason for introducing this deprecation notice is to start highlighting
possible problems in codebases where nobody even suspected them before.
In one application recently I actually had the string "false" (coming
Hello Internals,
After the first discussion about this topic
(https://externals.io/message/117608) I have created a preliminary
implementation and an RFC for making implicit boolean type coercions
more strict:
https://wiki.php.net/rfc/stricter_implicit_boolean_coercions
With this email I'm
On 16.05.22 18:24, Guilliam Xavier wrote:
Thanks! Am I right that it only affects *type declarations*, and the
"Unaffected PHP Functionality" section could also mention implicit
boolean evaluation in `if`, ternary conditional (?:) and logical
operators (!, &&, ||, and, or, xor)?
Yes, that is
Hello Internals,
I opened the vote about Stricter implicit boolean coercions as
announced. The vote will run until 2022-06-20.
Discussion: https://externals.io/message/117732
RFC: https://wiki.php.net/rfc/stricter_implicit_boolean_coercions
Best regards,
Andreas Leathley
The vote has been closed, the RFC has been declined with 14 to 3 votes.
It would have been interesting to get some more feedback on why people
voted No - some took part in the discussion, but most didn't. My
assumption is that most didn't find this important enough, especially if
strict types is
On 23.05.22 20:58, Juliette Reinders Folmer wrote:
All in all, I largely agree with the flaws in this proposal as
previously pointed out by Christian Schneider in the preliminary
discussion. And I don't see those concerns addressed in the RFC (other
than making it more explicit what the actual
On 24.05.22 15:33, Dan Ackroyd wrote:
"When discussion ends, and a minimum period of two weeks has passed"
Fyi, the two weeks is a minimum, and almost certainly not enough time
for subtle BC breaking RFCs like this.
I explicitely stated that to make it clear that this should be
considered a
On 02.05.22 13:56, Alexandru Pătrănescu wrote:
The point is that this is not an usual deprecation, something that will
change to an error in the future.
In the end, it's just a change in behavior with no error before or after.
It does not fit the "deprecation".
As I dealt with several PHP
On 13.04.22 15:36, Craig Francis wrote:
On Mon, 11 Apr 2022 at 20:08, Andreas Leathley wrote:
You are taking parts of the documentation out of context, and omitting
the start of the whole "Converting to string" section:
"A value can be converted to a string using th
On 26.04.22 16:36, Rowan Tommins wrote:
On 26/04/2022 14:53, Andreas Leathley wrote:
'on' is only true by "accident" though, because it is a non-empty
string, not because of its meaning, and then it is likely that the value
'off' could also be added at some point - which also wou
On 07.05.22 22:59, Jordan LeDoux wrote:
I like the way you organized the different levels of support within the
feature, it's a good organizational structure for thinking about the
feature-set. Given the feedback though, I found myself a little concerned
that if I created a Level 1 proposal,
On 26.08.22 11:00, Michał Marcin Brzuchalski wrote:
A `json_decode()` is a substitute that IMO solves 99% of use cases.
If I'd follow your logic and accept every small addition that handles 1% of
use cases, somebody will raise another RFC
for simplexml_validate_string or yaml_validate and the
On 13.12.22 13:53, Dan Liebner wrote:
It breaks my app. Does that count?
This sounds like you completely ignore notices in your application yet
elevate warnings to exceptions/errors. It would be better to log both
notices and warnings without generating exceptions/errors, and look
through
On 13.12.22 11:01, Robert Landers wrote:
intended: ($a['foo'] ?? null) || ($a['bar'] ?? null)
Further, writing code like this increases the number of opcodes needed
to perform relatively simple logic by ~150%, increasing end-user
latency and spending CPU cycles somewhat needlessly.
I think it
On 10.04.23 01:44, Deleu wrote:
Over the course of PHP 7 and 8, there were significant concerns on how
problematic PHP deprecations and breaking changes were. Now we're starting
to see the result of such concerns being ignored. This isn't the first time
someone mentions on PHP internals that
On 11.04.23 15:56, Jeffrey Dafoe wrote:
So turn off the deprecation warnings for now. They're just a heads up that
behaviour is going to change in the future, with PHP 9.
I doubt you'd prefer not to be aware of the change well in advance.
Oh, absolutely. We run those "on" in our dev and QA
80 matches
Mail list logo
