Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi, I added some examples, corrected incorrect explanations, etc. Now that the specifications have been fairly finalized and the RFC has been clarified, I would like everyone to check it out again. https://wiki.php.net/rfc/support_object_type_in_bcmath Regards. Saki

Re: [PHP-DEV][DISCUSSION] Fix mb_trim inaccurate $character

2024年4月4日(木) 6:30 Tim Düsterhus : > > Hi > > On 4/3/24 10:02, youkidearitai wrote: > > Therefore, I think require an RFC, I have written a draft an RFC that > > fixes these issues. > > https://wiki.php.net/rfc/mb_trim_change_characters > > I don't think this (widening the type and changing the defa

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Jordan, > It looks pretty good. It should probably give specific guidelines on how "no > scale provided" works for addition, subtraction, multiplication, division, > and exponentiation. The section now doesn't make it clear that the returned > scale will behave differently for addition (the

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

On Wed, Apr 3, 2024 at 7:31 PM Saki Takamachi wrote: > > Thanks, I agree with you that it works a little differently than the > existing BCMath function, so it needs to be well-documented. > > I have summarized the discussion so far, made some corrections, and > updated the RFC. I would be happy

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Barney, Jordan, > Right, if a class is not final but has only final methods (including > constructor) and no protected properties then it allows people to extend it > but not break any encapsulation or (I think) impose any more BC requirements > on the maintainer (unless we care about confli

Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type

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 decimal(1.03, precision: 2) / 2 - decimal(0.515, 3)? > decimal(0.51,

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

On Tue, Apr 2, 2024 at 5:43 PM Saki Takamachi wrote: > > If make a class final, users will not be able to add arbitrary methods, so > I think making each method final. Although it is possible to completely > separate behavior between method and opcode calculations, this is > inconsistent and conf

Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions

If there are no more comments, I would like to put this RFC to vote in the next two days.

Re: [PHP-DEV][DISCUSSION] Fix mb_trim inaccurate $character

Hi On 4/3/24 10:02, youkidearitai wrote: Therefore, I think require an RFC, I have written a draft an RFC that fixes these issues. https://wiki.php.net/rfc/mb_trim_change_characters I don't think this (widening the type and changing the default value to obtain the *intended* behavior) require

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

On 03/04/2024 01:42, Saki Takamachi wrote: If make a class final, users will not be able to add arbitrary methods, so I think making each method final. Right, if a class is not final but has only final methods (including constructor) and no protected properties then it allows people to exten

Re: [PHP-DEV] Requiring GPG Commit Signing

Hi [Resending, because my mail server failed to look up php.net. It looks good now, I apologize for duplicate copies.] On 4/3/24 19:28, John Coggeshall wrote: That's really unfortunate (why even bother). IMO without some sort of web of trust verification process for GPG, this just feels like

Re: [PHP-DEV] [RFC][Concept] Data classes (a.k.a. structs)

Hi Larry On Wed, Apr 3, 2024 at 12:03 AM Larry Garfield wrote: > > On Tue, Apr 2, 2024, at 6:04 PM, Ilija Tovilo wrote: > > > I think you misunderstood. The intention is to mark both call-site and > > declaration. Call-site is marked with ->method!(), while declaration > > is marked with "public

Re: [PHP-DEV] Requiring GPG Commit Signing

> > Having GPG key requirements is all fine and dandy I suppose, but my > > tongue-in-cheek comment above has a real point behind it: GPG keys > > don't mean jack if you can't trust who owns the key. > > GitHub doesn't show the web of trust anyway, just "verified". Command > line GIT doesn't either

Re: [PHP-DEV] Requiring GPG Commit Signing

On Tue, 2 Apr 2024, John Coggeshall wrote: > > > So if we want to make sure that something like XY doesn't happen, we > > have to add some additional restrictions to those GPG keys. > > Looks like all those geeky colleagues of ours back in the day having > key-signing parties at conferences wer

Re: [PHP-DEV] Requiring GPG Commit Signing

On Tue, 2 Apr 2024, Ayesh Karunaratne 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). > > +1 from me as well, and quite goo

Re: [PHP-DEV] First time contributor (DateTime::setDate PR)

On Tue, 2 Apr 2024, Bilge wrote: > On 02/04/2024 14:14, Derick Rethans wrote: > > > > On Sun, 31 Mar 2024, Bilge wrote: > > > > > About the PR: I sometimes find it would be useful to only update > > > part of the date. The PR makes all parameters to > > > DateTime(Immutable)::setDate > > >

[PHP-DEV][DISCUSSION] Fix mb_trim inaccurate $character

Hi, Internals Found two problem with mb_trim, mb_ltrim and mb_rtrim functions. - https://github.com/php/php-src/issues/13789 - https://github.com/php/php-src/issues/13815 Therefore, I think require an RFC, I have written a draft an RFC that fixes these issues. https://wiki.php.net/rfc/mb_trim_cha