L.s.,
I've just been looking in detail at the Partially Supported Callables
deprecation RFC:
https://wiki.php.net/rfc/deprecate_partially_supported_callables
The RFC explicitly excludes the `is_callable()` function and the
`callable` type from throwing deprecation notices.
The
On 23-3-2022 14:46, Rowan Tommins wrote:
On 20/02/2022 18:55, Rowan Tommins wrote:
I would like to open discussion on an RFC to deprecate and later
remove the functions utf8_encode() and utf8_decode()
https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode
Final chance for feedback
On 11-9-2023 1:57, Ben Ramsey wrote:
I agree. Using uppercase for the first letter in an acronym and
lowercase for subsequent letters appears to be prevalent in many
userland libraries, so it seems to be what users expect.
Since class names in PHP aren't case-sensitive, there should be no BC
On 15-9-2023 12:15, Dmitry Stogov wrote:
Hi,
After the code-review feedback, one of the most questionable decisions was
changed.
Instead of including IR Framework as a git submodule, now its part is
embedded into php-src.
This will complicate the IR/JIT development a bit, but will simplify
On 13-9-2023 17:48, Ben Ramsey wrote:
On 9/10/23 20:59, Juliette Reinders Folmer wrote:
With the above in mind, I wonder how much confusion/code churn
renaming existing classes will cause and if that's worth it,
especially as the suggested case for the PHP native class will likely
On 18-8-2023 17:27, Ilija Tovilo wrote:
Hi everyone
Since https://wiki.php.net/rfc/new_in_initializers we can store
objects in global constants. However, we may not actually read or
write to the properties of those objects without first fetching the
constant into a local variable.
const a =
On 22-4-2022 3:02, php-internals_nos...@adviesenzo.nl wrote:
On 21-4-2022 21:56, Andreas Hennings wrote:
On Thu, 21 Apr 2022 at 11:18, Rowan Tommins wrote:
On Wed, 20 Apr 2022 at 19:16, Claude Pache wrote:
You make a very important claim in your bug report:
However, in real world,
On 18-3-2022 14:37, Christoph M. Becker wrote:
On 16.03.2022 at 06:52, Juliette Reinders Folmer wrote:
I've just been looking in detail at the Partially Supported Callables
deprecation RFC:
https://wiki.php.net/rfc/deprecate_partially_supported_callables
The RFC explicitly excludes
Hi Dan,
On 29-5-2022 17:34, Dan Ackroyd wrote:
Actually, I've just realised there is an error in the code in the RFC,
which might be based on a misconception caused by how terrible
callables are. In the code:
if (is_callable('static::methodName')) {
// For valid callbacks, this call will
L.S.,
I have opened the vote on the "Expand deprecation notice scope for
partially supported callables" RFC:
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices
The vote will run for two weeks and will close on June 14, 10:30 UTC.
The discussion threads about
On 12-5-2022 18:54, Juliette Reinders Folmer wrote:
After the prior discussion about the same topic:
https://externals.io/message/117342, I have created an RFC to expand
the scope of the deprecation notices being thrown for the deprecated
partially supported callables to include is_callable
After the prior discussion about the same topic:
https://externals.io/message/117342, I have created an RFC to expand the
scope of the deprecation notices being thrown for the deprecated
partially supported callables to include is_callable() and the callable
type in PHP 8.2.
With this email
On 16-5-2022 17:06, Andreas Leathley wrote:
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:
On 26-5-2022 20:23, Dan Ackroyd wrote:
Hey Julie,
On Thu, 26 May 2022 at 12:45, Juliette Reinders Folmer
wrote:
I propose to open the vote on this RFC tomorrow.
Before you open the vote, please could you split the voting into two,
one for the is_callable, and one for the callable type check
On 12-5-2022 23:30, Claude Pache wrote:
Le 12 mai 2022 à 23:11, Larry Garfield a écrit :
For the `callable` type declaration, I'm not opposed but is it redundant with
the existing deprecation? When would you pass a callable to something and not
end up calling it anyway, which would
On 31-5-2022 12:38, Juliette Reinders Folmer wrote:
L.S.,
I have opened the vote on the "Expand deprecation notice scope for
partially supported callables" RFC:
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices
The vote will run for two weeks and
L.S.,
I have opened the vote on the "Expand deprecation notice scope for
partially supported callables" RFC:
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices
The vote will run for two weeks and will close on June 14, 10:30 UTC.
The discussion threads about
L.S.,
I have opened the vote on the "Expand deprecation notice scope for
partially supported callables" RFC:
https://wiki.php.net/rfc/partially-supported-callables-expand-deprecation-notices
The vote will run for two weeks and will close on June 14, 10:30 UTC.
The discussion threads about
On 29-4-2022 16:36, Rowan Tommins wrote:
On 29/04/2022 03:04, Juliette Reinders Folmer wrote:
And that's basically exactly what I already did which led me to
discover the patterns I posted about as they looked concerning
(though I didn't use Nikic's tool, but the WIP PHPCompatibility
sniff
On 1-5-2022 9:54, Rowan Tommins wrote:
On 1 May 2022 03:49:11 BST, Juliette Reinders Folmer
wrote:
As far as I understand it, if the deprecation notice is **only** thrown for the
deprecated callables, the code can always be adjusted to use the recommended
replacement code patterns as per
On 22-4-2022 8:47, Rowan Tommins wrote:
On 22 April 2022 02:02:58 BST, php-internals_nos...@adviesenzo.nl wrote:
I agree it would be a good idea to run a package analysis, but to be fair, in
all honesty that should have been done for the original RFC, which was
completely missing an impact
On 28-4-2022 21:42, Rowan Tommins wrote:
On 28/04/2022 15:09, Juliette Reinders Folmer wrote:
Ah! So you're basically asking for the impossible. Search for a code
pattern where a deprecation would not be useful, while noone has been
able to come up with one.
Not at all. I'm saying look
On 28-4-2022 17:00, Christoph M. Becker wrote:
On 28.04.2022 at 16:09, Juliette Reinders Folmer wrote:
On 22-4-2022 8:47, Rowan Tommins wrote:
On 22 April 2022 02:02:58 BST,php-internals_nos...@adviesenzo.nl wrote:
I agree it would be a good idea to run a package analysis, but to be
fair
On 2-5-2022 14:43, Rowan Tommins wrote:
On 02/05/2022 12: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
L.S.,
As per the progression of the discussion about the deprecated partially
supported callable, a new RFC is needed to expand the scope of the
deprecations. See: https://externals.io/message/117342
I'd like to request karma to create this RFC.
Username: jrf
Kind Regards,
Juliette
On 18-8-2022 15:46, Jakub Zelenka wrote:
Make libxml_set_external_entity_loader() return the previous loader
https://github.com/php/php-src/pull/7977
Based on the PR, this introduces a new function to PHP/the `libxml`
extension. Doesn't that need an RFC ?
Note: I'm not opposed to the change
On 18-8-2022 19:12, Jakub Zelenka wrote:
On Thu, Aug 18, 2022 at 5:11 PM Juliette Reinders Folmer <
php-internals_nos...@adviesenzo.nl> wrote:
On 18-8-2022 15:46, Jakub Zelenka wrote:
Make libxml_set_external_entity_loader() return the previous loader
https://github.com/php/php-src/pul
On 5-8-2022 19:08, Larry Garfield wrote:
Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3:
Asymmetric Visibility.
https://wiki.php.net/rfc/asymmetric-visibility
Details are in the RFC, but it's largely a copy of Swift's support for the same.
For what it's worth, here's
On 2-11-2022 18:46, Benjamin Morel wrote:
Hi internals,
It just came to my attention that there is a change of behaviour between
PHP 8.1 and 8.2 in the way iterable is decomposed, or not, into
Traversable|array when reflected:
```
function foo(): iterable {}
function bar(): stdClass|iterable
On 24-4-2023 12:28, Daniil Gentili wrote:
Hi all,
I've submitted https://github.com/php/php-src/pull/11126 to add
support for final anonymous classes, though as noted by iluuu1994, it
would probably make more sense to just make all anonymous classes
final by default, what do you think?
On 6-4-2023 0:12, Vorisek, Michael wrote:
Hello,
I would like to open a discussion for
https://github.com/php/php-src/issues/10791 .
Hi all,
I'm running into something which peaked my curiousity due to its
unexpected behaviour, so I'm writing to the list in the hopes of finding
out whether this is by design, a bug or an oversight which should be
fixed (via an RFC?).
> The precedence order is that members from the current
On 15-6-2023 5:47, Levi Morrison via internals wrote:
Hello, PHP Internals,
I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.
This can be a useful tool for a few reasons:
1. It can make implementing an interface easier when
On 3-6-2023 21:11, Dan Ackroyd wrote:
Hi internals,
I'm now opening the discussion for the Closure self-reference RFC:
https://wiki.php.net/rfc/closure_self_reference
This was previously discussed as a draft here:
https://externals.io/message/112216#112216
Thank-you to KapitanOczywisty for
RFC authors,
I just noticed that the PHP 8.3 "PDO driver specific sub-classes" RFC is
still listed as "in voting". The "Deprecate functions with overloaded
signatures" RFC is still listed as "pending implementation". As far as I
can see, both have been accepted/merged and can be moved to
On 6-8-2023 13:13, Juliette Reinders Folmer wrote:
RFC authors,
I just noticed that the PHP 8.3 "PDO driver specific sub-classes" RFC
is still listed as "in voting". The "Deprecate functions with
overloaded signatures" RFC is still listed as "pending
i
On 19-6-2023 23:27, Máté Kocsis wrote:
Hi Juliette,
For the mb_strimwidth() proposal an impact analysis is provided at the end
("over 100 projects were reviewed").
For the other proposals there isn't and we do not believe this to be
useful. We consider deprecations to be different from other
On 19-6-2023 23:16, Máté Kocsis wrote:
Hi,
The impact analysis on userland code seems to be missing for some of the
proposals, most notably for the proposals which I expect will have the
highest impact. I'd like to ask for an impact analysis to be added to
each of these:
* array_keys()
*
On 15-6-2023 9:18, Máté Kocsis wrote:
Hi everyone,
As there was no discussion and complaint for a long time, we would like to
move forward with the RFC. We believe Go and Tim answered Nikita's doubts
elaborately, so we should make the question decided during the vote.
Therefore, we'll start
On 27-4-2023 23:28, Máté Kocsis wrote:
Hi Internals,
As you have possibly already experienced, overloaded signatures cause
various smaller and bigger issues, while the concept is not natively
supported by PHP. That's why I drafted an RFC which intends to phase out
the majority of overloaded
On 14-8-2023 16:17, G. P. B. wrote:
Hello internals,
While working on some DNF type bugs, I discovered some major issues around
the disable_classes INI setting implementation. Such as:
- A double-free of the type of a typed property
- A use after free (which segfaults) when trying to access a
On 22-1-2024 10:50, Gina P. Banyard wrote:
Hello internals,
Máté Kocsis and myself would like to propose deprecating implicitly nullable
parameter types.
The RFC is available on the wiki at the following address:
https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
Best regards,
On 23-1-2024 3:18, Gina P. Banyard wrote:
The RFC notes that PHPStan and friends have an easy flag to make the change,
which is great, but still that's a minority of PHP devs that even know to use
static analysis.
One does not need to use a static analyser to determine or fix this issue,
On 6-2-2024 3:40, youkidearitai wrote:
2024年2月6日(火) 8:33 Tim Starling :
On 2/2/24 20:27, youkidearitai wrote:
I see. I'll change mb_ucfirst using titlecase.
Per my comments a month ago on the GitHub issue , I think it is much better to
use title case for mb_ucfirst() than to use upper case,
L.S.,
What with all the drives towards cleaner code, how do people feel
nowadays about `extract()` and `compact()` still being supported ?
Both have alternatives. The alternatives may be a little more cumbersome
to type, but also make the code more descriptive, lessens the risk of
variable
On 10-11-2023 17:51, Jakub Zelenka wrote:
Hello,
I would like to propose a new process RFC for updates to PHP release cycle:
https://wiki.php.net/rfc/release_cycle_update
This has been discussed between release managers to make sure that all are
happy as some of the points impact release
On 24-2-2024 2:37, Gina P. Banyard wrote:
Hello internals,
I've been having this mild annoyance with exit()/die() since I wrote a CLI
script using a boolean $hasErrors variable to know if the script failed or not
and to indicate if the script failed via a non-zero status code by doing:
On 24-2-2024 3:47, Gina P. Banyard wrote:
On Saturday, 24 February 2024 at 01:57, Juliette Reinders Folmer
wrote:
Hi Gina,
I'm not sure a pet-peeve is a good motivation for creating an (I
expect large) breaking change.
The upgrade path, I suppose, would be updating calls to `die
On 14-3-2024 15:55, Matteo Beccati wrote:
Hi Sebastian,
Il 14/03/2024 14:15, Sebastian Bergmann ha scritto:
Am 14.03.2024 um 14:07 schrieb Matteo Beccati:
In my daily CI I have several builds failing today, eg.
* PHPUnit 9.6
See https://github.com/sebastianbergmann/phpunit/issues/5719.
On 6-4-2024 14:55, Tim Düsterhus wrote:
Hi
On 4/5/24 23:32, Juliette Reinders Folmer wrote:
I also took the liberty to ask accessibility expert Nicolas Steenhout
[1] for his opinion on this topic and he has given me permission to
quote his reply:
> From a human readabil
On 8-4-2024 23:39, Ilija Tovilo wrote:
Hi everyone
Heads-up: Larry and I would like to start the vote of the property
hooks RFC tomorrow:
https://wiki.php.net/rfc/property-hooks
We have worked long and hard on this RFC, and hope that we have found
some middle-ground that works for the
On 5-4-2024 19:48, Niels Dossche wrote:
On 05/04/2024 19:00, Tim Düsterhus wrote:
I've just written up the follow-up RFC to my previous “Casing of acronyms in
class and method names” thread and I'm officially opening up the discussion
period for it.
Please find the following links for your
On 5-4-2024 22:55, Larry Garfield wrote:
On Fri, Apr 5, 2024, at 7:15 PM, Tim Düsterhus wrote:
Hi
On 4/5/24 20:01, Juliette Reinders Folmer wrote:
In the "It decreases readability" section you make a sweeping statement
about accessibility, but don't back that up with research. P
On 9-4-2024 16:03, Juliette Reinders Folmer wrote:
On 8-4-2024 23:39, Ilija Tovilo wrote:
Hi everyone
Heads-up: Larry and I would like to start the vote of the property
hooks RFC tomorrow:
https://wiki.php.net/rfc/property-hooks
We have worked long and hard on this RFC, and hope that we have
Hi Ilija,
On 12-4-2024 1:00, Ilija Tovilo wrote:
On 9-4-2024 16:03, Juliette Reinders Folmer wrote:
I realize it is late in the discussion period to speak up, but for months I've
been trying to find the words to express my concerns in a polite and
constructive way and have failed.
First
On 8-5-2024 15:40, Gina P. Banyard wrote:
I would like to formally propose my idea for exit() as a function brought up to
the list on 2024-02-24 [1] with the following RFC:
https://wiki.php.net/rfc/exit-as-function
There have been some slight tweaks to the implementation, namely that the
On 11-5-2024 16:43, Gina P. Banyard wrote:
On Thursday, 9 May 2024 at 15:17, Jorg Sowa wrote:
> I don't think there are any other "functions" like this.
What about list(), isset(), print(), echo(), require(), include(),
unset(), empty()? We use them the same way as functions, but those
are
57 matches
Mail list logo
