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
2024年3月26日(火) 23:49 youkidearitai :
>
> 2024年3月26日(火) 21:58 Peter Kokot :
> >
> > On Tue, 26 Mar 2024 at 06:41, youkidearitai wrote:
> > >
> > > Hi, Internals
> > >
> > > Sorry I mistake.
> > > Send again.
> > >
> > > grapheme_str_split going to "Voting" phase.
> > > Vote end is 10th April 00:00
postscript:
The `precision` of `round()` can be negative. I'm not sure if this should be
called `scale`.
Regards.
Saki
Hi Rowan,
a).
> I propose:
>
> - The constructor accepts string|int $num only.
>
> - All operations accept an optional scale and rounding mode.
>
> - If no rounding mode is provided, the default behaviour is to truncate. This
> means that (new BCMath\Number('20'))->div(3, 5) has the same
Hi Tim,
> I don't see a change made, so perhaps I was unclear in what I said. What I
> meant was: Please add a full stub example including all the interfaces,
> properties, and methods. It's currently split across multiple code blocks and
> the interfaces are missing entirely.
>
> Example:
>
> Instead, we are planning to re-propose asymmetric visibility once
> property hooks are merged, as it may become more apparent why it is
> useful.
I was talking today to a co-worker about this internals e-mail discussion
and he thought asymmetric visibility was inherent to property-hooks.
He
On Tue, Apr 9, 2024, at 7:49 PM, Tim Düsterhus wrote:
> However I'm not sure if adding new array functions piecemeal is the
> right choice at this point. array_any and array_every are conceptually
> very similar to array_find and are missing as well. In fact
> array_any($cb, $array) =
Hi Robert
On Tue, Apr 9, 2024 at 9:34 PM Robert Landers wrote:
>
> On Tue, Apr 9, 2024 at 8:56 PM Larry Garfield wrote:
> >
> > The Aviz RFC was put to a vote last year but didn't pass.
>
> It would be really nice if votes weren't just a yes/no vote, but
> yes/needs-more-work/no vote, where
Hi
On 4/9/24 21:32, Robert Landers wrote:
The Aviz RFC was put to a vote last year but didn't pass.
It would be really nice if votes weren't just a yes/no vote, but
yes/needs-more-work/no vote, where needs-more-work and no are
effectively the same in terms of passing the RFC, but
Hi
On 4/7/24 21:10, Joshua Rüsweg wrote:
On 07.04.24 16:35, Larry Garfield wrote:
1. Should this work on arrays or iterables? This is a long standing limitation
of PHP. The array operations don't work on iterables, even though we've had
iterables for 20 years.)
In the longer term, it
>
> On Mon, Apr 8, 2024, at 6:08 AM, Valentin Udaltsov wrote:
> > Hello internals,
> >
> >
> >
> > I would like to propose a syntax change for PHP 8.4 that allows to
> > immediately access instantiated objects without wrapping the expression
> > into parentheses.
> >
> >
> >
> > This was requested
On Tue, Apr 9, 2024 at 8:56 PM Larry Garfield wrote:
>
> On Tue, Apr 9, 2024, at 4:07 PM, Levi Morrison wrote:
>
> > I was playing around with 3v4l.org. Is the implementation up-to-date there?
> >
> > I don't have any hard objections at the moment, but after playing with
> > it for a while, I do
On 24/03/2024 13:13, Saki Takamachi wrote:
https://wiki.php.net/rfc/support_object_type_in_bcmath
Based on the various discussions we've been having, I'd like to propose
a simplified handling of "scale".
I think there are two groups of users we are trying to help:
a) Users who want an
Hi
On 4/8/24 02:08, Saki Takamachi wrote:
- The full “stub” should probably include an explicit "implements Stringable"
for clarity.
Agree. I describe it explicitly during implementation.
I don't see a change made, so perhaps I was unclear in what I said. What
I meant was: Please add a
Hi
On 4/8/24 14:00, Pablo Rauzy wrote:
So what should be done to move forward with this?
Should the old RFC on strict argument count be revived?
Or should a new RFC proposal be written? If so, should it contain an
It should be a new "v2" RFC. The old RFC already contains a vote, thus
Hi
On 4/9/24 13:02, Derick Rethans wrote:
It seems that most of the reply to this was positive, although with the
realisation that it wouldn't be a panacea.
I will therefore propose a minimalistic RFC to create this requirement
to sign commits to all branches, in the next few days.
I
On Tue, Apr 9, 2024, at 4:07 PM, Levi Morrison wrote:
> I was playing around with 3v4l.org. Is the implementation up-to-date there?
>
> I don't have any hard objections at the moment, but after playing with
> it for a while, I do kind of wonder if it's a lot of complexity for
> what is
I haven't verified the implementation, but as long as there really
aren't backwards compatibility issues for correct code, then this
would be a nice quality of life improvement.
On Mon, Apr 8, 2024 at 3:42 PM 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
On Tue, Apr 9, 2024 at 7:52 PM Derick Rethans wrote:
> Adding a new native type to PHP will create a large change. Not only is
> it "just" adding a new native type, it also means all of the conversions
> between types need to be added. This is not a small task.
I understand this :)
> If you
On Mon, Apr 8, 2024, at 6:08 AM, Valentin Udaltsov wrote:
> Hello internals,
>
>
>
> I would like to propose a syntax change for PHP 8.4 that allows to
> immediately access instantiated objects without wrapping the expression
> into parentheses.
>
>
>
> This was requested and discussed several
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
> - Use precision instead of scale
> - The default maximum precision is 20 digits
> - The default rounding mode is HALF_UP
> - The constructor takes only $num arguments
> - The method can optionally specify any precision and any rounding mode when
> calculating
> - Operators always use only
Hi Internals,
I have opened the vote on https://wiki.php.net/rfc/deprecate-get-post-sessions
It will close on 2024-04-23
Regards,
Kamil
Hi,
To be honest, I think it would be much easier to use if we could make it look
like this:
- Use precision instead of scale
- The default maximum precision is 20 digits
- The default rounding mode is HALF_UP
- The constructor takes only $num arguments
- The method can optionally specify any
On Tue, 2 Apr 2024, Derick Rethans wrote:
> What do y'all think about requiring GPG signed commits for the php-src
> repository?
>
> I had a look, and this is also something we can enforce through GitHub
> as well (by using branch protections).
It seems that most of the reply to this was
On Wed, 3 Apr 2024, Jordan LeDoux wrote:
> On Mon, Mar 18, 2024 at 1:35 PM Rowan Tommins [IMSoP]
> wrote:
>
> >
> > Where things get more complicated is with *fixed-precision* decimals,
> > which is what is generally wanted for something like money. What is the
> > correct result of
On Thu, 7 Dec 2023, Alex Pravdin wrote:
> Accounting for all of the above, I suggest adding a native numeric
> scalar arbitrary precision type called "decimal". Below are the
> preliminary requirements for implementation.
Adding a new native type to PHP will create a large change. Not only is
Hi,
there have been no further comments on the release cycle update RFC
thread, so I'm hereby opening the RFC for voting.
Voting will end on Monday April 29th, at noon UTC (20 days, instead of
the required minimum of 14):
https://wiki.php.net/rfc/release_cycle_update#proposed_voting_choices
On 8 April 2024 21:51:46 BST, Jordan LeDoux wrote:
>I have mentioned before that my understanding of the deeper aspects of how
>zvals work is very lacking compared to some others, so this is very
>helpful.
My own knowledge definitely has gaps and errors, and comes mostly from
introductions
30 matches
Mail list logo
