d
instead exposing the functionality *only* via the new Enum.
Especially as those constant have not yet been in a stable release of PHP.
Other than that, and seeing the confusing of some other people, maybe using the
names "TowardsPositiveInfinity" and "TowardsNegativeInfinity" is better.
Best regards,
Gina P. Banyard
inus 1.
It should also be noted that ceil/floor is very English specific terminology
that may not be immediately obvious to non-English speakers, thus my preference
for using some variation of towards positive/negative infinity.
Best regards,
Gina P. Banyard
On Tuesday, 28 May 2024 at 15:26, Derick Rethans wrote:
> On Mon, 27 May 2024, Ilija Tovilo wrote:
>
> > On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard intern...@gpb.moe
> > wrote:
> >
> > > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard
> > >
On Monday, 27 May 2024 at 02:31, Ilija Tovilo wrote:
> Hi Gina
>
> On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard intern...@gpb.moe wrote:
>
> > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard intern...@gpb.moe wrote:
> >
> > > I would like to
but if that's how you see it fine.
If that's the only reason for keeping proper parsing rules, I'm not sure
whether that's worthwhile IMHO.
Best regards,
Gina P. Banyard
exit is invalid.
Moreover, in other programming languages exit() is a function, and I don't see
a reason for having something be a language construct when there is no need for
it.
Best regards,
Gina P. Banyard
On Tuesday, 14 May 2024 at 17:24, Juliette Reinders Folmer
wrote:
> On 11-5-2024 16:43, Gina P. Banyard wrote:
>
>> On Thursday, 9 May 2024 at 15:17, Jorg Sowa
>> [](mailto:jorg.s...@gmail.com) wrote:
>>
>>>> I don't think there are any other "functions
is is an orthogonal issue to this one, and one that
has long existed in the language.
Every other internal attribute that has been added to PHP has some visible
effects to the user, having it do nothing seems rather odd to me.
Best regards,
Gina P. Banyard
0 indexed based is to be consistent with
the existing semantics.
So I am fine with having it 0 indexed.
Best regards,
Gina P. Banyard
[1] https://www.php.net/manual/en/reflectionparameter.getposition.php
>
://wiki.php.net/rfc/exit-as-function
> >
> > There have been some slight tweaks to the implementation, namely that the
> > transformation from a "constant" to a function is done at compile time and
> > we do not hook into the behaviour of constants any longer.
> >
>
I don't know the last time I've used those language constructs "like a
function".
Hope this clarifies things.
Best regards,
Gina P. Banyard
On Saturday, 11 May 2024 at 09:05, Juliette Reinders Folmer
wrote:
> 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.
tanding is that in this case I don't
> think it makes any difference to the user.
ACK.
I feel this RFC has been brought to a vote too early, as such I am changing my
vote to no.
I am generally in favour of the concept, but there are too many details that
are unanswered or didn't even get proper attention for me to feel comfortable
with the state of the RFC in question.
Best regards,
Gina P. Banyard
[1]
https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md
[2]
https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md
to true like a "standard" object, or does a Number equal to 0 cast to
false?
- Considering the property hook RFC has been accepted, should the $value
property be a "virtual" property or not?
Best regards,
Gina P. Banyard
On Friday, 3 May 2024 at 16:47, Derick Rethans wrote:
> On Fri, 3 May 2024, Gina P. Banyard wrote:
>
> > On Thursday, 2 May 2024 at 21:33, Derick Rethans der...@php.net wrote:
> >
> > > On 2 May 2024 13:48:36 BST, Ollie Read php@ollie.codes wrote:
> > >
>
tionFunctionAbstract::getParameters() API did not exist, this is
what I would have pushed for.
Moreover, PHP already has a 1-indexed and 0-indexed discrepancy with the
ob_get_level() and ob_get_status() functions.
In the end, I don't really care what we choose, but this just needed
clarification from internals on how to proceed.
Best regards,
Gina P. Banyard
ECL for this
exact reason.
Thus adding, effectively, a new database driver makes no sense to me.
Best regards,
Gina P. Banyard
aintain a specific PDO Driver they can do so themselves
and publish it on PECL, same as how CUBRID (and others) does currently.
Best regards,
Gina P. Banyard
>
to introducing this new enum and
signature change.
The only thing I could think of is if this enum should be in a new Maths (or
Math or just Mathematics to not need to deal with regional difference in the
short spelling of "Mathematics") namespace.
Best regards,
Gina P. Banyard
[1] http
mes to be the
one as currently defined, so it might produce diffs depending on which version
of PHP the tool is ran on.
The output of tests could be affected.
Maybe this change is better suited for PHP 9?
Best regards,
Gina P. Banyard
On Wednesday, 28 February 2024 at 15:24, Gina P. Banyard
wrote:
> Hello internals,
>
> I have opened the vote for the "Deprecate implicitly nullable parameter
> types" RFC:
> https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
>
> It will run for tw
of PHP 8.4.
Best regards,
Gina P. Banyard
FC that used offsetWrite()
instead of offsetSet() for the method name of the DimensionWrite interface.
Best regards,
Gina P. Banyard
s with the
property HashTable directly.
My current PR to fix all those weird behaviours is to use the write_property
object handler with ZEND_GUARD_PROPERTY_SET guard set.
I don't know how hooks are implemented so Ilija should be able to determine how
this works exactly, but my guess is that it should "just work" with set hooks
being called.
>
> Again, thank you for your work on this, and I hope it passes easily.
>
> --Larry Garfield
Hope I've answered the questions you had.
Best regards,
Gina P. Banyard
represented as an integer.
So round *must* be able to return a float.
Best regards,
Gina P. Banyard
backing type to be mixed well you are just required
to write a typed property with type mixed, same as readonly.
Best regards,
Gina P. Banyard
[1] https://wiki.php.net/rfc/parameter-no-type-variance
mass
deprecation RFC to this one, as I would be very odd to have this accepted but
not the latter.
Best regards,
Gina P. Banyard
Hello internals,
I have opened the vote for the "Deprecate implicitly nullable parameter types"
RFC:
https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
It will run for two weeks until the 13th of March 2024.
Best regards,
Gina P. Banyard
e same as the array
cast, is how do backed/virtual properties interact with
get_mangled_object_vars()
Best regards,
Gina P. Banyard
on a wide-reaching platform with minimal interaction from core developers?
Is the objective to just propose, announce, and discuss RFCs and vote on them?
etc.
Probably each of these objectives require different solutions, and this would
probably be a more useful conversation to have.
Best regards,
Gina P. Banyard
s one type
juggling context.
I realize that I probably should have just spent time writing an RFC and doing
the discussion directly, as I'm effectively laying out the arguments why we
should do this in an email.
Best regards,
Gina P. Banyard
ual ones, because the current one is just confusing.
I am also not sure what would make this a large breaking change, as changing
this from a language construct to a function provides us with more capabilities.
Best regards,
Gina P. Banyard
, before I spend more time on this and write a proper RFC, do people
think this is a good idea or not?
Best regards,
Gina P. Banyard
Hello internals,
I updated the RFC to encompass all the feedback:
https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
Let me know if there are any final remarks before we start the vote sometime
next week.
Best regards,
Gina P. Banyard
mpile time type redundancy check. [2]
Note: traits and unbound Closures would still require a way to provide the
"scope" but those seem to be cases of limited use for analysing/comparing
ReflectionTypes.
Best regards,
Gina P. Banyard
[1] https://github.com/php/php-src/pull/11460
[2] If
rayAccess can have some peculiar behaviour, but this is because the
underlying engine handlers are also complex.
I think this change makes sense and will keep it in mind/add it to my RFC.
Best regards,
Gina P. Banyard
-revs file so that git blame doesn't care about them.
This should resolve the issue of making future merges difficult.
Best regards,
Gina P. Banyard
ch _technically_ breaks the handling of options
that require a callables, as the callable is checked to exist _when_ attempting
to call it and not when actually passing it to curl_setopt.
But this should change anyway if I merge my PR which "fixes" this. [1]
Best regards,
Gina P. Banyard
[1] https://github.com/php/php-src/pull/13291
hat's kinda irrelevant.
It would be nice to have some formatting rules to harmonize the codebase as it
is somewhat the wild west,
but as far as my understanding goes is that Clang format struggles to
understand our codebase (namely macros) and is difficult to set-up for php-src.
Best regards,
Gina P. Banyard
On Tuesday, 30 January 2024 at 20:52, Gina P. Banyard wrote:
> On Monday, 29 January 2024 at 11:59, Gina P. Banyard g...@gpb.moe wrote:
>
> > Hello internals,
> >
> > I just opened the vote for the Add http_(get|clear)_last_response_headers()
> > function RFC
_header variable so
that it can be removed.
This is a rather fringe feature, and thus I expect these functions to also be a
fringe feature.
Best regards,
Gina P. Banyard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ribe, visit: https://www.php.net/unsub.php
I started the vote started yesterday.
I don't see a point in extending it by two weeks to have a total voting of 4
weeks + 2 days.
Best regards,
Gina P. Banyard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Monday, 29 January 2024 at 11:59, Gina P. Banyard wrote:
> Hello internals,
>
> I just opened the vote for the Add http_(get|clear)_last_response_headers()
> function RFC:
> https://wiki.php.net/rfc/http-last-response-headers
>
> Vote will run for two weeks and end on
On Tuesday, 23 January 2024 at 16:37, Larry Garfield
wrote:
> On Tue, Jan 23, 2024, at 2:18 AM, Gina P. Banyard wrote:
>
> > I fundamentally disagree with the logic that we somehow need to "plan"
> > deprecations around how much time we need to provide
On Tuesday, 23 January 2024 at 02:45, Juliette Reinders Folmer
wrote:
> 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
>
rcing coding styles and is capable of fixing this issue.
This tool and other code formatting tools are used more widely and for longer
than static analysers.
Best regards,
Gina P. Banyard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
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,
Gina P. Banyard
--
PHP Internals - PHP Runtime
lowing the
discussion difficult.
Best regards,
Gina P. Banyard
[1] https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hello internals,
I have updated the RFC to include a motivation and rejected ideas section:
https://wiki.php.net/rfc/http-last-response-headers
Unless there is further discussion, I intend to open the vote for the RFC on
Wednesday the 24th of January.
Best regards,
Gina P. Banyard
>
On Thursday, 18 January 2024 at 20:08, Niels Dossche
wrote:
> Hi Gina
>
> On 18/01/2024 14:05, Gina P. Banyard wrote:
>
> > Hello Niels,
> >
> > Thank you for the RFC and the thorough overview of the current state.
> >
> > I think converting th
odes which never throw?
Best regards,
Gina P. Banyard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
n then if you want IEEE
754 behaviour for division you need to use fdiv() as of PHP 8.0 as any division
by 0 throws this error since
https://wiki.php.net/rfc/engine_warnings#division_by_zero got accepted.
I think this change makes sense but would rather have an improved wording/Error
as proposed
essage/120409
I think it makes sense to add this in general.
Best regards,
Gina P. Banyard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Wednesday, 3 January 2024 at 14:38, Michał Marcin Brzuchalski
wrote:
> Hi Gina,
> śr., 3 sty 2024 o 14:41 Gina P. Banyard napisał(a):
>
>> Hello internals,
>>
>> I would like to propose an RFC to add the functions
>> http_get_last_request_headers() an
On Wednesday, 3 January 2024 at 14:34, Aleksander Machniak wrote:
> On 3.01.2024 14:41, Gina P. Banyard wrote:
>
> > Link: https://wiki.php.net/rfc/http-last-response-headers
>
>
> Wrong function name in the subject (should be "response" not "request&quo
r
is violating LSP, and probably a test should be added for this.
Best regards,
Gina P. Banyard
Hello internals,
I would like to propose an RFC to add the functions
http_get_last_request_headers() and http_clear_last_request_headers() to PHP to
replace the magic variable $http_response_header.
Link: https://wiki.php.net/rfc/http-last-response-headers
Best regards,
Gina P. Banyard
tering a custom class
is not very powerful and rather cumbersome to use as the constructor is
never called.
As such, I'm not sure if I would support adding the current mechanism to
customize the node classes returned by the extension. Indeed, the current
mechanism doesn't play nicely at all with static analysis and this is
something I stopped trying to integrate when writing my DocBook renderer
project. [1]
Best regards,
Gina P. Banyard
[1] https://gitlab.com/Girgias/docbook-renderer
ning: Uncaught TypeError: Unsupported operand types:
> > Decimal\Decimal + Decimal\Decimal in
> >
> > So, it appears not.
> >
>
> I've pointed out this issue earlier in the discussion and Gina P. Banyard
> has replied that this can be a PHP 8.3 bug and he will look int
On Tue, 12 Dec 2023 at 21:00, Robert Landers
wrote:
> On Tue, Dec 12, 2023 at 2:04 PM G. P. B. wrote:
> > GMP supports operator overloading
>
> GMP kinda-sorta-most-of-the-time supports operator overloading.
> Sometimes ... it doesn't. I implemented a field library in PHP (f
Gina P. Banyard
On Tue, 12 Dec 2023 at 08:51, Alexander Pravdin
wrote:
> I just found out that under PHP 8.3, basic arithmetic operations on the
> Decimal object variables are no longer supported and cause TypeError. So
> this is one more point to implementing native decima
On Fri, 8 Dec 2023 at 10:14, Alexander Pravdin
wrote:
> On Thu, Dec 7, 2023 at 11:36 PM G. P. B. wrote:
>
> - Objects are always casted to true, GMP(0) will equal to true.
>>>
>>
>> This is incorrect, GMP object do _not_ support casts to bool
>> See https:/
ternal and attribute-marked classes.
>
I do agree, adding a isSerializable() function to ReflectionClass is a good
idea.
Best regards,
Gina P. Banyard
My thoughts here are mostly from the user's perspective, I'm
> not so familiar with PHP internal implementation. But I think this feature
> can be a good goal for PHP 9.
>
Yes, this is a major project, and as said above I have also thought about
adding a rational number type.
But the main hurdle for this is changing the zval structure and applying
the change everywhere to the engine and extensions.
Best regards,
Gina P. Banyard
gt;
> [1]: https://www.php.net/manual/en/function.mb-strpos.php
> [2]: https://www.php.net/manual/de/function.mb-substr.php
> [3]: https://www.php.net/manual/de/function.mb-strstr.php
>
This might have been better to raise as a bug, but in any case I am CCing
Alex who's the main maintainer of the mbstring extension so he's aware of
this and can possibly provide some explanations.
Best regards,
Gina P. Banyard
On Fri, 1 Dec 2023 at 09:35, Jakub Zelenka wrote:
> On Fri, Dec 1, 2023 at 9:28 AM G. P. B. wrote:
>
>> On Thu, 30 Nov 2023 at 23:45, Jakub Zelenka wrote:
>>
>>> Hi,
>>>
>>> On Thu, Nov 30, 2023 at 10:13 PM Jorg Sowa wrote:
>>>
>>&g
is declined as you need 2/3 of votes to pass...
>
This seems to be a secondary vote which only requires 50% of votes to be
accepted.
Best regards,
Gina P. Banyard
xplicitly
kept in check by using external tools such as static analysis tools, or
code style tools.
And removing those, or making the language overall more coherent and
consistent, requires us to break backwards compatibility.
Sincerely,
Gina P. Banyard
[1] https://go.dev/doc/go1compat:
> It is
kly is probably something we should be doing, and that people
paid by the foundation should convert resources to opaque objects in PECL
extensions, and other extensions brought to our attention.
And yes, that also means helping Oracle with OCI8 that is getting unbundled.
I will try to get round to do ext/dba somewhat soon.
Best regards,
Gina P. Banyard
November. I’m very
> sorry for the confusion.
>
> Cheers,
> Ben
>
Does this mean any bug-fix merged into 8.2 already needs to be backported?
Or will 8.1 RMs do this?
Best regards,
Gina P. Banyard
implementation having issues [4]
Sincerely,
Gina P. Banyard
[1] https://github.com/php/php-src/issues/12725
[2] https://github.com/php/php-src/pull/11774
[3] https://github.com/php/php-src/issues/9344
[4] https://github.com/php/php-src/pull/12731
ody pointed this out before.
>
> I don't have any objection to the rounding modes themselves.
>
Personally I am fine with adding aliases to ext/intl, it is not because the
extension is a wrapper that we can't enhance it to be somewhat consistent.
However, I do agree that deprecating the existing constants is a bad idea.
But the RFC vote, as far as I can understand, is not about deprecating it
in this release.
Best regards,
Gina P. Banyard
The change seems to be uncontroversial, so an RFC feels unnecessary here.
Just make a PR and I think we can merge this into master.
Best regards,
Gina P. Banyard
m-4632-36hf
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
This sounds sensible to me.
Best regards,
Gina/George P. Banyard
r, I'm not very convinced at the moment that such a function is truly
useful.
Best regards,
Gina/George P. Banyard
es and interfaces.
And needing to declare every alias in every single file of a project is a
ludicrous idea.
Best,
Gina/George P. Banyard
people to think
stuff through and handle things like polymorphic comparisons.
Also, introducing some new kind of weird operator is just... bad.
Best regards,
George P. Banyard
On Tue, 10 Oct 2023 at 14:52, G. P. B. wrote:
> Hello internals,
>
> While doing some refactoring of ext/xml to bring it up to modern engine
> standards, I discovered some peculiar behaviour of the functions which set
> callable handlers.
>
> The PR in question is: https://g
point of it.
Best regards,
George P. Banyard
o also deprecate this feature out right, but this can be done
by adding it to the mass 8.4 deprecation RFC. [1]
Point of this email is to know if anyone has any complaints about this BC
break before merging the PR into master.
Best regards,
George P. Banyard
[1] https://wiki.php.n
p.net/rfc/deprecations_php_8_4
Best regards,
George P. Banyard
part a warning is emitted).
I see no benefit in doing this weird approach instead of just changing the
behaviour.
Yes this is a theoretical BC break [1], but unless you can show me an
actual use case that breaks (and even then) I don't think the approach of
this RFC is good.
Best regards,
George
Instead, these extensions should be
> considered
> > as a collection of different components, and should be namespaced
> according
> > to these.
>
>
> Does anyone have a good suggestion?
>
If there needs to be a namespace, we could take inspiration from Python and
use OS\Process,
as everything relating to processes seem to reside in the os module.
Best regards,
George P. Banyard
rent "broken"
implementation, which was broken with 7.0 and the move to 64bit integers.
As such, I would just make the behaviour of returning integers the default
behaviour in 8.4.
If, for some weird reason, people want less accurate numbers, they can
always cast the input to float.
Best regards,
George P. Banyard
be at least one version where both variants exist to allow
for cross version compatibility.
I will also echo Tim's idea of using an enum instead and a union type.
For the namespace, I think it would make sense to use Maths\RoundingMode
Best regards,
George P. Banyard
functions for BCMath makes a lot of sense to me.
Best regards,
George P. Banyard
i
>
I don't know about removing the silent mode altogether, but I think the
warning version is pretty useless.
However, if we are going to remove it, it would be nice to have this done
consistently across all bundled extensions.
>From the top of my head, I know SQLite3 and the Intl extension also have
such flags, and possibly the DOM extension too.
Best regards.
George P. Banyard
does nothing other than cause
segfaults.
This functionality is broken, and frankly has always been.
The only reason I am asking for an exception is to remove broken
functionality that doesn't work and cannot be easily fixed.
George P. Banyard
rst RC.
I have CCed the RMs for 8.3, and would like the opinion of other people on
if this removal makes sense to the majority of people
Sincerely,
George P. Banyard
[1] https://externals.io/message/2076
ng an RFC for those kinds of things. As self-contained, small features
do not necessarily require them.
Best regards,
George P. Banyard
PS: Side note, please do not bottom post.
Best,
George P. Banyard
On Wed, 28 Jun 2023 at 17:09, G. P. B. wrote:
> Hello internals,
>
> I'm opening the vote for the
> Deprecate remains of string evaluated code assertions RFC:
> https://wiki.php.net/rfc/assert-string-eval-cleanup
>
> It will last for two weeks and end on Wednesday the 12t
On Wed, 28 Jun 2023 at 17:07, G. P. B. wrote:
> Hello internals,
>
> I'm opening the vote for the Path to Saner Increment/Decrement operators
> RFC:
> https://wiki.php.net/rfc/saner-inc-dec-operators
>
> It will last for two weeks and end on Wednesday the 12th of July
>
the implementation of a default method is far from
concrete.
Requiring an implementation to provide the implementation for seek(int
$position)
But being able to provide the trivial implementation of rewind() which is
seek(0);
Sincerely,
George P. Banyard
Hello internals,
I'm opening the vote for the
Deprecate remains of string evaluated code assertions RFC:
https://wiki.php.net/rfc/assert-string-eval-cleanup
It will last for two weeks and end on Wednesday the 12th of July
Best regards,
George P. Banyard
Hello internals,
I'm opening the vote for the Path to Saner Increment/Decrement operators
RFC:
https://wiki.php.net/rfc/saner-inc-dec-operators
It will last for two weeks and end on Wednesday the 12th of July
Best regards,
George P. Banyard
ould have no side effects) and changing it to void very clearly
conveys this meaning that one must not store the result of the assert() as
it is not a totally normal function call.
Best regards,
George P. Banyard
On Tue, 17 Jan 2023 at 14:28, G. P. B. wrote:
> Hello Internals,
>
> I would like to start the discussion on the Path to Saner
> Increment/Decrement operators RFC:
> https://wiki.php.net/rfc/saner-inc-dec-operators
>
> The goal of this RFC is to reduce language complexity by
On Wed, 31 May 2023 at 13:08, G. P. B. wrote:
> Hello internals,
>
> I would like to start the discussion about deprecating various remains
> from the now removed string code evaluated assertions functionality of
> assert().
>
> The RFC is located on the wiki at the follo
On Wed, 31 May 2023 at 23:20, Claude Pache wrote:
> Although your RFC says that the `zend.assertions` ini setting has
> superseded `assert.active` for a while, the “official” php.ini file still
> advises to modify the value of `assert.active` rather than the one of
> `zend.assertion` in order to
1 - 100 of 488 matches
Mail list logo
