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
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
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
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
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
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
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
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
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
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
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
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
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
>
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,
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
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
>
_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
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
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 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
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
, 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
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
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
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
e same as the array
cast, is how do backed/virtual properties interact with
get_mangled_object_vars()
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
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
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
represented as an integer.
So round *must* be able to return a float.
Best regards,
Gina P. Banyard
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
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
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
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
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:
> > >
>
://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
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
>
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
>
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
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
48 matches
Mail list logo
