s it would be a clear sign to me that what people want from the project is
something that I find completely nonsensical and thus I should direct my energy
and time to something more inline with my own design beliefs.
Sincerely,
Gina P. Banyard
>
[1] https://github.com/php/php-src/pull/18320
thout a proper RFC, is to explain my reasoning for why I
am voting against the never parameter type RFC. [3]
For any questions, feel free to reply, but please do remember that this is
still a bit in flux.
Best regards,
Gina P. Banyard
[1] https://thephp.foundation/blog/2024/08/19/state-of-ge
uncky [1] mentioning the possibility of bad
interactions with default interface methods (something I think is more
important than this) is reinforcing my opinion that this RFC solve the problem
in a bad way.
And another user [2] was basically suggesting my previous solution of adding
suppor
On Sunday, 20 October 2024 at 18:42, Gina P. Banyard wrote:
> Hello internals,
>
> I would like to propose a short RFC to make the return value of the sort()
> and similar functions more useful:
> https://wiki.php.net/rfc/array-sort-return-array
>
> I intend for the discu
On Thursday, 20 March 2025 at 16:57, Larry Garfield
wrote:
> On Thu, Mar 20, 2025, at 11:24 AM, Gina P. Banyard wrote:
>
> > As the person that had the initial discussion in R11 with Jordan [1]
> > never as a parameter type for an interface actually is not the solution
never parameter type to a generic parameter type is a BC
break.
Thus, I am not sure this really a good idea.
The argument from Alwin is more compelling but considering we don't have
conditional types, not sure if this makes sense either.
Best regards,
Gina P. Banyard
[1] https://chat.stackoverflow.com/transcript/11?m=52810456#52810456
[2] https://externals.io/message/126698#126791
On Tuesday, 11 March 2025 at 21:17, Rowan Tommins [IMSoP]
wrote:
> On 11/03/2025 11:54, Gina P. Banyard wrote:
>
> > It also means that we need to do multiple passes, on the same code path,
> > resulting in somewhat of a code churn and possibly not using a commo
h could for example look
like:
$obj implements OptionalDependency;
someFunctionFromOptionalDependency($obj);
which gives control to the *user* where and how class instance may interact
with dependencies that are outside of your control, and that you don't even
need to care of.
Best regards,
Gina P. Banyard
>
ile still holding the ext/pcntl version
behind while you deal with the issues.
(Bonus points, the issue where PIE is currently unable to install bundled
extension [1] would be solved with unbundling too.)
Best regards,
Gina P. Banyard
[1] https://github.com/php/pie/issues/133
itting E_DEPRECATED instead of E_WARNING/throwing a ValueError,
we are incentivising people to add throwing error handlers for E_DEPRECATED,
something that I (and I know others too) lament constantly, as a deprecation is
not an error.
Best regards,
Gina P. Banyard
>
y prefer to not introduce those
> classes without namespace or prefix.
Those two classes predate the Namespaces in bundled PHP extensions [1] RFC, I
do think adding a namespace is better.
And we could also move the two classes into the new namespace and add class
aliases for the global on
good to merge.
Best regards,
Gina P. Banyard
>
any iterations and been in discussion
for so long is because Máté tried, again and again, to have a common interface.
But this just does not make any sense, you cannot make something extremely
concrete vague and abstract, unless you want to lose all the benefits of the
abstraction.
Best regards,
Gina P. Banyard
[1] https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle
[2]
https://wiki.php.net/rfc/url_parsing_api#why_a_common_uri_interface_is_not_supported
of this RFC is to provide this
API to other core extensions, the previous objections do not apply here.
Best regards,
Gina P. Banyard
able to really implement a monad if
you want to support partial success.
So I'm not sure mentioning the lack of monadic support in PHP is the best
argument against them for this RFC.
Best regards,
Gina P. Banyard
On Friday, 28 June 2024 at 21:06, Máté Kocsis wrote:
> Hi Everyone,
>
>
work without issues.
This is good motivation for me to go back and push the by-value sort() RFC [1]
as it uses that mechanism.
I've also submitted a PR [1] to add such a test case.
Probably a good idea to specify this in the RFC.
Best regards,
Gina P. Banyard
[1] https://wiki.php.net/rfc/array-sort-return-array
[2] https://github.com/Crell/php-src/pull/1
alues from the DB.
But this issue already exists with positional arguments.
And the constructor could do something completely different with the provided
arguments that do not interfere at all with values coming from the DB.
Hope this clarifies the behaviour.
Best regards,
Gina P. Banyard
inconsistency.
Thoughts?
For reference, this is effectively the same point I raised in a previous
internals thread, which didn't really get much attention. [5]
Best regards,
Gina P. Banyard
[1]
https://sourcegraph.com/search?q=context:global+lang:C+zend_fcall_info_args_ex+-file:zend_
On Thursday, 21 November 2024 at 10:05, Christian Schneider
wrote:
> Am 14.11.2024 um 22:27 schrieb Gina P. Banyard intern...@gpb.moe:
>
> > Agreed, this bites us constantly when needing to reason about what an
> > "object" is in PHP.
> > Similar to arra
directly.
> (With union types you can even do so in a BC fashion much of the time.)
Agreed, this bites us constantly when needing to reason about what an "object"
is in PHP.
Similar to array it mixes the concept of a struct, with that of a reference
value, and "overloading&qu
lete nonsense and not
receivable.
Best regards,
Gina P. Banyard
te_partially_supported_callables#discussion
The callable type is allowed as a parameter and return type, and Closure is
"better" defined than just callable.
Best regards,
Gina P. Banyard
;t think I have the time/bandwidth to work on this, so if anyone wants
something "easy" to work on that would be it.
Best regards,
Gina P. Banyard
merged as is.
Best regards,
Gina P. Banyard
[1] https://github.com/php/php-src/pull/15492
plit out because they are different scopes.
It is *fine* to have smaller incremental RFCs that build on top of each other
without needing to provide justification as to why it was punted to later.
Arguably, the onus should be on people wanting it to be in the RFC to do the
research and provide some implementation idea to have them be one RFC for this
discussion to be at all reasonable.
Best regards,
Gina P. Banyard
lways easier to add new features than to deprecate and
remove bad ones (which is kinda backwards but not relevant to this discussion).
Best regards,
Gina P. Banyard
.
Especially as supporting it would remove the last good reason to keep the
callable type, which is to define a list of callables statically.
Best regards,
Gina P. Banyard
upport. :)
I think adding this is a no-brainer.
Best regards,
Gina P. Banyard
n are "true compile
time constants")
Best regards,
Gina P. Banyard
>
On Monday, 21 October 2024 at 14:29, Ilija Tovilo
wrote:
> Hi Gina
>
> On Mon, Oct 21, 2024 at 3:21 PM Gina P. Banyard intern...@gpb.moe wrote:
>
> > On Sunday, 20 October 2024 at 18:42, Gina P. Banyard intern...@gpb.moe
> > wrote:
> >
> > > https://w
On Sunday, 20 October 2024 at 18:42, Gina P. Banyard wrote:
> Hello internals,
>
> I would like to propose a short RFC to make the return value of the sort()
> and similar functions more useful:
> https://wiki.php.net/rfc/array-sort-return-array
I am going to respond out of
Hello internals,
I would like to propose a short RFC to make the return value of the sort() and
similar functions more useful:
https://wiki.php.net/rfc/array-sort-return-array
I intend for the discussion to last 2 weeks and then open the vote.
Best regards,
Gina P. Banyard
On Thursday, 3 October 2024 at 17:06, Gina P. Banyard wrote:
> Hello internals,
>
> I have opened the vote for the Change Directory class to behave like a
> resource object RFC:
> https://wiki.php.net/rfc/directory-opaque-object
>
> The vote will last for two weeks unti
> Now I don't know what to believe. shrugs
>
> Kind regards,
> Bilge
Yeah, this is wrong.
Every single minor version of PHP dating all the way back to PHP 4.0.0 has had
BC breaks.
The thing is, I don't even know what:
> Source compatibility should be kept if possible, while breakages are allowed
means here.
Best regards,
Gina P. Banyard
Hello internals,
I have opened the vote for the Change Directory class to behave like a resource
object RFC:
https://wiki.php.net/rfc/directory-opaque-object
The vote will last for two weeks until the 17th of October 2024.
Best regards,
Gina P. Banyard
argument presented on the list that Enums should still
be returned by get_declared_list() because they are "classes":
Interfaces and traits are also "classes" internally, and yet they are not
returned.
We make a distinction in userland, and this should be followed by the provided
functions.
Best regards,
Gina P. Banyard
ch in
their favourite thing that many of us have no idea how to use.
Best regards,
Gina P. Banyard
n used
in type declarations since possibly PHP 5.0 is a non-starter IMHO.
Best regards,
Gina P. Banyard
On Tuesday, 24 September 2024 at 13:25, Gina P. Banyard
wrote:
> On Saturday, 14 September 2024 at 16:33, Gina P. Banyard intern...@gpb.moe
> wrote:
>
> > Hello internals,
> >
> > I came across the Directory class while doing some code exploration of
> >
On Wednesday, 25 September 2024 at 10:12, Nick Lockheart
wrote:
> On Sat, 2024-09-14 at 15:33 +, Gina P. Banyard wrote:
> I don't suppose we could call the Directory class something else, like
> "SPLDirectory"?
>
> You can't make a Directory with `new` (o
> Just checking here if anyone objects to this or thinks this needs an RFC.
>
> Kind regards
> Niels
I don't think this needs an RFC considering it is very similar to $innerHTML,
and it is based on the DOM spec.
Best regards,
Gina P. Banyard
On Tuesday, 24 September 2024 at 14:34, Christian Schneider
wrote:
> Am 14.09.2024 um 17:33 schrieb Gina P. Banyard intern...@gpb.moe:
>
> > I came across the Directory class while doing some code exploration of
> > ext/standard.
> > This class is effectively an opa
On Tuesday, 24 September 2024 at 14:24, Christoph M. Becker
wrote:
> On 24.09.2024 at 14:18, Gina P. Banyard wrote:
>
> > I would like to propose a short RFC about warning on conversions from
> > resources to strings,
> > similar to what a conversion from array to stri
On Saturday, 14 September 2024 at 16:33, Gina P. Banyard
wrote:
> Hello internals,
>
> I came across the Directory class while doing some code exploration of
> ext/standard.
> This class is effectively an opaque object for Directory resources, however
> it doesn't beh
Hello internals,
I would like to propose a short RFC about warning on conversions from resources
to strings,
similar to what a conversion from array to string does.
Let me know what you think about it:
https://wiki.php.net/rfc/warn-resource-to-string
Best regards,
Gina P. Banyard
On Friday, 20 September 2024 at 15:09, Christoph M. Becker
wrote:
> On 20.09.2024 at 15:00, Gina P. Banyard wrote:
>
> > This leads to a rather insane situation where the engine does not assume +
> > is always commutative but does so for *, something which
}
The other thing, which is different from the previous proposal, and becomes
more relevant if we use functions, is that I think that they should be static
methods that take the left and right operands instead of assuming it is on the
left and/or needing a boolean argument indicating if it is on the left or not.
I am still planing on going through an overhaul of PHP comparison semantics, as
indicated by my existing draft, but this might take a while.
Best regards,
Gina P. Banyard
[1] https://wiki.php.net/rfc/operator_overloading_gmp
tions
for doing this bump) and people were already uncomfortable at the timeline I
proposed when the RFC got voted;
I found it better to let another deprecation free version for people to move to
str_increment().
I did not forget about this and had it on the planned list of things to tackle
for PHP 8.5.
Best regards,
Gina P. Banyard
On Saturday, 14 September 2024 at 18:48, Christoph M. Becker
wrote:
> On 14.09.2024 at 17:33, Gina P. Banyard wrote:
>
> > I came across the Directory class while doing some code exploration of
> > ext/standard.
> > This class is effectively an opaque object for Dire
On Monday, 16 September 2024 at 18:31, Derick Rethans wrote:
> On Sat, 14 Sep 2024, Gina P. Banyard wrote:
>
> > I came across the Directory class while doing some code exploration of
> > ext/standard. This class is effectively an opaque object for Directory
> > resou
l/15847
> [2] https://github.com/php/php-src/issues/15723
> [3] https://github.com/php/php-src/pull/15847#issuecomment-2345774089
> [4] https://github.com/php/php-src/pull/13669
I think this makes sense and I'm in favour of having this part of 8.4.
Best regards,
Gina P. Banyard
to an opaque object.
RFC: https://wiki.php.net/rfc/directory-opaque-object
Best regards,
Gina P. Banyard
ot;.
We are on the internals mailing list, obviously "we" refers to internals here.
Best regards,
Gina P. Banyard
r traits considering all the issues I can foresee happenning.
Best regards,
Gina P. Banyard
>
/snmp are actually
maintained.
Having added support for PIE for ext/csv, which was very easy, [2] I hope when
this tool is finally ready, and we ditch PECL, we will start unbundling
extensions so that they are not constrained by the PHP Engine release cycle.
Best regards,
Gina P. Banyard
[1]
https://wiki.php.net/rfc/deprecations_php_8_4#xml_set_object_and_xml_set_handler_with_string_method_names
[2]
https://gitlab.com/Girgias/csv-php-extension/-/commit/ab978521e4d3bde15b73838d4605c5e5178ba082
FC I have no idea how you are tackling the global namespace
fallback, nor how you are going to prevent the lookup happening multiple times.
As such in the current state I will vote against it, and be annoyed that you
are making me do busy work.
Best regards,
Gina P. Banyard
e.
Having the php.net website point to various curated tutorials, industry
standard packages and tools, seems fairly natural.
And not doing this clearly makes us an outlier rather than the norm.
This is not to say we should mention everything under the sun on the website,
but this is where d
s, you have sent the vast majority of emails on this
list, this is not what I would consider normal nor expected for your level of
"seniority" (for the lack of better word) on the project.
This is not to say to stop posting and replying, just to do it in a more
conscious manner for the rest of us reading you.
Best regards,
Gina P. Banyard
>
makes sense to remove the
zend_autoload_class function pointer API and have the VM directly call
zend_autoload.
Because from what I remember 2 years ago, some profiling tools hook into it to
track autoloading time.
This might be improved by introducing new observer hooks.
Best regards,
Gin
you introduce the constant later in the RFC.
However, I will echo another message in that this should be an enum because it
is a new API.
Forcing the user to specify the context in which this function is called also
seems like a good idea.
Best regards,
Gina P. Banyard
sagree from a
language design principle.
I do tend to agree with Rowan that Stringable and the __toString() magic method
overall is.... less than ideal.
Best regards,
Gina P. Banyard
ng value for enumeration is for
serialization purposes.
There have been numerous discussion on this list about this topic, with plenty
of people stating their opinions.
Best regards,
Gina P. Banyard
>
On Tuesday, 13 August 2024 at 14:05, Matthew Sewell wrote:
> > On 13 Aug 2024, at 12:36, Gina P. Banyard intern...@gpb.moe wrote:
> >
> > On Tuesday, 30 July 2024 at 11:49, Gina P. Banyard intern...@gpb.moe wrote:
> >
> > > Hello Internals,
> > >
On Tuesday, 30 July 2024 at 11:49, Gina P. Banyard wrote:
> Hello Internals,
>
> I have just opened the vote for the "Transform exit() from a language
> construct into a standard function" RFC:
> https://wiki.php.net/rfc/exit-as-function
>
> The vote will last
al need to
> increase the requirement to C11, you can always do that.
Even with this change we would not be fully C99 compliant, as we do rely on GCC
extensions AFAIK.
Moreover, a bunch of us *want* to move to C11/C17.
C11 is a standard that is 13 years old, and C99 is 25 years old, I think
On Sunday, 11 August 2024 at 15:26, Pierre Joye wrote:
> On Sun, Aug 11, 2024, 6:53 PM Gina P. Banyard wrote:
>
>> On Saturday, 10 August 2024 at 15:13, Christoph M. Becker
>> wrote:
>>
>> I think moving the PDO driver to use C++ is a more sensible choice.
&g
c2c130f504c18ebeeac828847f17f1f8f7c3559b8fe8b2bc19928
>
> [4] https://github.com/FirebirdSQL/firebird/issues/8197
>
> [5] https://github.com/winlibs
>
>
> Cheers,
> Christoph
I think moving the PDO driver to use C++ is a more sensible choice.
Best regards,
Gina P. Banyard
etoed by core developers.
And once again, I still do not have any idea why Derick has issues adding
support to XDebug.
Especially as Tim seemingly managed to do this while being unfamiliar with the
codebase.
Best regards,
Gina P. Banyard
Or am I.missimg something?
In theory, it is the RFC idea.
In practice, a lot of the times it is the patch for complex features.
However, it is still within the purview of core developers to veto the
implementation of an RFC.
Which could be the case here rather than voting against the RFC outright.
Best
On Monday, 5 August 2024 at 23:55, Christoph M. Becker
wrote:
> On 05.08.2024 at 21:37, Gina P. Banyard wrote:
>
> > This sounds like a uopz extension issue that is easily fixed.
>
>
> Most likely, yes, although still somebody has to provide a fix, and
> someone has t
that eval() was having are non-existing here.
Best regards,
Gina P. Banyard
hat accidential attempts to override exit with
> `uopz_set_return()` were silently ignored, but unless `uopz.exit=1` is
> set, or `uopz_allow_exit(true)` is called, exit is ignored. Especially
> the latter may be relied upon by tests for legacy code.
>
> Christoph
This sounds like a uopz extension issue that is easily fixed.
I am not sure why we should bend over backwards for extensions that allow to
break usual userland semantics while preventing userland behaviour to be better.
Best regards,
Gina P. Banyard
On Monday, 5 August 2024 at 12:04, Derick Rethans wrote:
> On Tue, 30 Jul 2024, Christoph M. Becker wrote:
>
> > On 30.07.2024 at 11:49, Gina P. Banyard wrote:
> >
> > > I have just opened the vote for the "Transform exit() from a
> > > languag
old compilers still being the default on LTS
Distributions.
The main benefit of C11/17 in the long run are atomics, that we kinda use
already anyway.
Moreover, as someone that has written an extension that has some usage, when I
go back to it, I'd rather like to be able to use features from C23 than be
stuck on C99, but that is just me.
Best regards,
Gina P. Banyard
>
On Friday, 19 July 2024 at 19:39, Gina P. Banyard wrote:
> Hello internals,
>
> I have opened the vote for the mega deprecation RFC:
> https://wiki.php.net/rfc/deprecations_php_8_4
>
> Reminder, each vote must be submitted individually.
2 days late but I have now closed th
On Tuesday, 30 July 2024 at 13:47, Christoph M. Becker
wrote:
> Hi Gina!
>
> On 30.07.2024 at 11:49, Gina P. Banyard wrote:
>
> > I have just opened the vote for the "Transform exit() from a language
> > construct into a standard function" RFC:
> > h
On Saturday, 13 July 2024 at 16:05, Gina P. Banyard wrote:
> Hello Internals,
>
> I have just opened the vote for the "Make the GMP class final" RFC:
> https://wiki.php.net/rfc/gmp-final
>
> The vote will last for 2 weeks from today July 13th 2024 to July
why I was expecting something else, but I guess I am just
disappointed.
I suppose we are truly becoming Oracle.
Sincerely,
Gina P. Banyard
[1] https://x.com/valorin/status/1816593881791860963
this.
> PR link: https://github.com/php/php-src/pull/15047
>
> Kind regards
> Niels
I think this makes sense and is a nice convenience addition.
Best regards,
Gina P. Banyard
Hello internals,
I have opened the vote for the mega deprecation RFC:
https://wiki.php.net/rfc/deprecations_php_8_4
Reminder, each vote must be submitted individually.
Best regards,
Gina P. Banyard
;
> Best regards
> Tim Düsterhus
I am also of the same opinion.
The benefit of this is marginal.
And if this requires a semicolon, the benefit is even lower by effectively just
typing one less character.
Best regards,
Gina P. Banyard
On Tuesday, 25 June 2024 at 15:36, Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to add
> in PHP 8.4:
>
> https://wiki.php.net/rfc/deprecations_php_8_4
>
> As a reminder, this list has been compile
On Thursday, 4 July 2024 at 14:52, Gina P. Banyard wrote:
> Hello internals,
>
> I would like to formally open the discussion on an RFC I've been working on
> for the past year:
> https://wiki.php.net/rfc/container-offset-behaviour
>
Hello internals,
Ilija did
On Monday, 8 July 2024 at 04:04, Juliette Reinders Folmer
wrote:
> On 2-7-2024 20:05, Gina P. Banyard wrote:
>> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer
>> wrote:
>>
>>> * While a number of proposals include an impact analysis (thank you!), a
Hello Internals,
I have just opened the vote for the "Make the GMP class final" RFC:
https://wiki.php.net/rfc/gmp-final
The vote will last for 2 weeks from today July 13th 2024 to July 24th 2024.
Best regards,
Gina P. Banyard
have incorrect floating
point semantics for people that rely on proper IEEE 754 floating points,
and yet we still have a silent change in behaviour due to the partial bugfix.
Moreover, these fixes made the implementation of round() more complicated, for
marginal benefits IMHO.
Best regards,
Gina P. Banyard
[1] https://wiki.php.net/rfc/change_the_edge_case_of_round
;compare" is used for class methods.
>
> e.g.
> https://www.php.net/manual/ja/splpriorityqueue.compare.php
> https://www.php.net/manual/ja/collator.compare.php
>
> Therefore, follow these conventions and rename `comp()` to `compare()`.
Thank you, I am happy will all the provided amendments now!
Best regards,
Gina P. Banyard
ey and
> value is removed from the ReverseWeakMap.
Isn't this use case already solved with WeakReferences?
https://www.php.net/manual/en/class.weakreference.php
Best regards,
Gina P. Banyard
>
e original
SplObjectStorage one.
One could also just extend both methods and have them differ in implementations.
I really believe there isn't a good way to solve this problem other than not
having any aliases within class methods.
Best regards,
Gina P. Banyard
ons that tries to triage new notes, I am strongly in
favour.
Unrelated, it would be very nice if we could improve the spam filters for user
notes somewhat, but this is unrelated to removing unpopular votes.
One question, should this possibly become a monthly cron job that checks for
the user
k changing the name of the append()
method is a good idea, will it hurt adoption in the short term for some
classes, yes, but I prefer this than having a large part of the ecosystem
needing to create an alias just for some weird cases.
Best regards,
Gina P. Banyard
[1] https://www.php.net/manual/en/splobjectstorage.offsetexists.php
[2] https://3v4l.org/E8BcK
On Thursday, 4 July 2024 at 14:52, Gina P. Banyard wrote:
> Hello internals,
>
> I would like to formally open the discussion on an RFC I've been working on
> for the past year:
> https://wiki.php.net/rfc/container-offset-behaviour
>
> As DokuWiki is a bit of a f
ld have way more discussion if you were not proposing
this when feature freeze is fast approaching and people are trying to wrap up
RFCs they have worked on for the past year.
For the sake of your proposal, I would seriously reconsider proposing this
prior to September.
Sincerely,
Gina P. Banyard
>
mplementation::getFeature() is deprecated,
> throw manually an Error exception instead.”
Just removing it makes sense, I'll talk to Niels about it, to change what the
vote is actually about.
Best regards,
Gina P. Banyard
[1] https://wiki.php.net/rfc/deprecated_attribute
[2] https://github.com/php/php-src/pull/14750
the same for string offset, i.e. they are invalid and will
throw an Error.
This is described in the "Invalid offsets" subsection of the "Strings" section.
[1]
And I am not proposing any changes to them.
Best regards,
Gina P. Banyard
[1]
https://github.com/Girgias/php-rfcs/bl
/blob/master/container-offset-behaviour.md
The implementation is basically done, other than some mysterious JIT issues
that I haven't been able to pinpoint yet.
Best regards,
Gina P. Banyard
lias of --enable-apache2handler configure option.
>
> Let me know if you find any server that can't or hasn't been upgraded
> to Apache 2.4 yet and if this should be postponed after PHP 8.4,
> otherwise merge is on its way for PHP 8.4.
I am also in favour of removing support for this in PHP 8.4.
Best regards,
Gina P. Banyard
On Tuesday, 25 June 2024 at 15:36, Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to add
> in PHP 8.4:
>
> https://wiki.php.net/rfc/deprecations_php_8_4
>
> As a reminder, this list has been compile
On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer
wrote:
> On 25-6-2024 16:36, Gina P. Banyard wrote:
>
>> Hello internals,
>>
>> It is this time of year again where we proposed a list of deprecations to
>> add in PHP 8.4:
>> https://wiki.php.
On Tuesday, 2 July 2024 at 07:49, Marc Bennewitz wrote:
> Hi Gina,
>
> On 25.06.24 16:36, Gina P. Banyard wrote:
>
>> Hello internals,
>>
>> It is this time of year again where we proposed a list of deprecations to
>> add in PHP 8.4:
>> https://wik
1 - 100 of 618 matches
Mail list logo
