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

> I'll try to think of some more good ideas, but if you have any suggestions, > please let me know. Regarding `$roundMode`, a possible approach is to clarify the priority of the current eight values, and if they are different, apply the one with the higher priority. With that in mind, the ques

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

postscript: For example, Ruby's operator overloading is not by design commutative, so in this case it's always possible to prioritize the properties of the left operand, but which can be a bit confusing.

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

Hi Tim, Jordan,On Fri, Apr 5, 2024 at 1:00 PM Tim Düsterhus wrote:Hi On 4/5/24 21:42, Saki Takamachi wrote: > The only solution I can think of at the moment is to impose the constraint that > when computing operator overloading, if the operands are both objects, they must > be

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

On 04/04/2024 23:31, Jordan LeDoux wrote: Well, firstly most of the financial applications that I've worked in (I work for a firm that writes accounting software right now) do not calculate intermediate steps like this with fixed precision, or even have an interest in doing so. My backgrou

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

On 5-4-2024 22:55, Larry Garfield wrote: On Fri, Apr 5, 2024, at 7:15 PM, Tim Düsterhus wrote: Hi On 4/5/24 20:01, Juliette Reinders Folmer wrote: In the "It decreases readability" section you make a sweeping statement about accessibility, but don't back that up with research. Please back your

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

On Fri, Apr 5, 2024, at 7:15 PM, Tim Düsterhus wrote: > Hi > > On 4/5/24 20:01, Juliette Reinders Folmer wrote: >> In the "It decreases readability" section you make a sweeping statement >> about accessibility, but don't back that up with research. Please back >> your statement up as based on my un

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

On Fri, Apr 5, 2024 at 1:00 PM Tim Düsterhus wrote: > Hi > > On 4/5/24 21:42, Saki Takamachi wrote: > > The only solution I can think of at the moment is to impose the > constraint that > > when computing operator overloading, if the operands are both objects, > they must > > be of the exact same

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

On Fri, Apr 5, 2024 at 12:42 PM Saki Takamachi wrote: > > The only solution I can think of at the moment is to impose the constraint > that when computing operator overloading, if the operands are both objects, > they must be of the exact same class. > > When calculating using a method, it is cle

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

Hi On 4/5/24 21:42, Saki Takamachi wrote: The only solution I can think of at the moment is to impose the constraint that when computing operator overloading, if the operands are both objects, they must be of the exact same class. Even that would allow for confusing behavior: class MyNumb

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

Hi On 4/5/24 20:30, Jordan LeDoux wrote:> Well, since they are both in Euros, I would expect 15, but I expect that was a typo considering the variable name and it was meant to be 10 USD. You are right of course. It should've read 10 USD. Frankly, I don't think that making it final actually

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

Hi,On Fri, Apr 5, 2024 at 2:48 AM Tim Düsterhus wrote:Hi Your `Money` example would allow for unsound and/or non-sense behavior, such as:      $fiveEuros = new Money(5, 'EUR');      $tenDollars = new Money(10, 'EUR');      $what = $fiveEuros + $tenDollars; What would you ex

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

Hi On 4/5/24 20:01, Juliette Reinders Folmer wrote: In the "It decreases readability" section you make a sweeping statement about accessibility, but don't back that up with research. Please back your statement up as based on my understanding, the opposite is true. For context: This paragraph w

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

>1. In session_start(), it is possible to override ini settings like that: > >```php >session_start([ 'use_cookies' => '1', 'use_only_cookies' => '1', >'referer_check' => '' ]); >``` > >The relevant options should also be deprecated in that context. Yes, they are. You can see that in my draft PR

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

On Fri, Apr 5, 2024 at 2:48 AM Tim Düsterhus wrote: > Hi > > Your `Money` example would allow for unsound and/or non-sense behavior, > such as: > > $fiveEuros = new Money(5, 'EUR'); > $tenDollars = new Money(10, 'EUR'); > > $what = $fiveEuros + $tenDollars; > > What would you expec

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

Hi Juliette On 05/04/2024 20:01, Juliette Reinders Folmer wrote: > On 5-4-2024 19:48, Niels Dossche wrote: >>> I support this proposal. >>> If accepted, I'll make the necessary changes to ext-dom and ext-xsl to >>> comply with the new policy. > Niels: just wondering what changes you are referring

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

On 5-4-2024 19:48, Niels Dossche wrote: On 05/04/2024 19:00, Tim Düsterhus wrote: I've just written up the follow-up RFC to my previous “Casing of acronyms in class and method names” thread and I'm officially opening up the discussion period for it. Please find the following links for your co

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

On 05/04/2024 19:00, Tim Düsterhus wrote: > Hi > > I've just written up the follow-up RFC to my previous “Casing of acronyms in > class and method names” thread and I'm officially opening up the discussion > period for it. > > Please find the following links for your convenience: > > RFC: http

[PHP-DEV] [RFC] Casing of acronyms in class and method names

Hi I've just written up the follow-up RFC to my previous “Casing of acronyms in class and method names” thread and I'm officially opening up the discussion period for it. Please find the following links for your convenience: RFC: https://wiki.php.net/rfc/class-naming-acronyms Previous ML dis

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

Le ven. 5 avr. 2024 à 18:04, Larry Garfield a écrit : > On Fri, Apr 5, 2024, at 2:20 PM, Joel Wurtz wrote: > >> Would it make sense to not only add this for ReflectionAttribute, but > also Function and/or others? > > > > There may be case where this makes sense but not necessarily in the use > >

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

On Fri, Apr 5, 2024, at 2:20 PM, Joel Wurtz wrote: >> Would it make sense to not only add this for ReflectionAttribute, but also >> Function and/or others? > > There may be case where this makes sense but not necessarily in the use > case that i explain, and don't want to add more to this proposa

[PHP-DEV] [RFC][Vote] Raising zero to the power of negative number

Hello everyone I've just opened voting for the RFC Raising zero to the power of the negative number Link: https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number Voting started now, and will end on April 20 2024, 00:00 UTC. Kind regards, Jorg

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

> Would it make sense to not only add this for ReflectionAttribute, but also Function and/or others? There may be case where this makes sense but not necessarily in the use case that i explain, and don't want to add more to this proposal, it's also missing in ReflectionParameter, ReflectionPropert

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

Hi Joel On Fri, Apr 5, 2024 at 3:10 PM Joel Wurtz wrote: > > Like a lot of libraries, we offer the possibility to configure behaviors with > Attributes. However in some cases it's wrongly configured by the user and > this wrong configuration cannot be detected on the attribute constructor but

Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions

On Thu, Apr 4, 2024, at 9:27 PM, Ilija Tovilo wrote: > On Thu, Apr 4, 2024 at 5:58 PM Tim Düsterhus wrote: >> >> On 4/4/24 16:36, Pablo Rauzy wrote: >> > I strongly agree in theory, but this could break existing code, and >> > moreover such a proposal was already rejected: >> > https://wiki.php.ne

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

On Fri, Apr 5, 2024, at 1:09 PM, Joel Wurtz wrote: > Hello everyone, > > Like a lot of libraries, we offer the possibility to configure > behaviors with Attributes. However in some cases it's wrongly > configured by the user and this wrong configuration cannot be detected > on the attribute cons

Re: [PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

On 5 April 2024 15:09:42 CEST, Joel Wurtz wrote: >Hello everyone, > >Like a lot of libraries, we offer the possibility to configure behaviors >with Attributes. However in some cases it's wrongly configured by the user >and this wrong configuration cannot be detected on the attribute >constructor b

[PHP-DEV] Proposal: retrieve line, filename and if user defined for ReflectionAttribute

Hello everyone, Like a lot of libraries, we offer the possibility to configure behaviors with Attributes. However in some cases it's wrongly configured by the user and this wrong configuration cannot be detected on the attribute constructor but afterwards. In this case we may want to pinpoint whi

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

Hi Tim, Barney, > Your `Money` example would allow for unsound and/or non-sense behavior, such > as: > > $fiveEuros = new Money(5, 'EUR'); > $tenDollars = new Money(10, 'EUR'); > > $what = $fiveEuros + $tenDollars; > > What would you expect to be in $what? A `BcMath\Number(15)`? > > -

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

On 05/04/2024 09:37, Saki Takamachi wrote: Hi Barney, Ah ok. Maybe that's the standard way internal classes are written, and we can consider it generally an error for a child class to override the constructor without calling `parent::__construct()`. I know tools warn users not to forget the

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

On 05/04/2024 10:48, Tim Düsterhus wrote: Your `Money` example would allow for unsound and/or non-sense behavior, such as:     $fiveEuros = new Money(5, 'EUR');     $tenDollars = new Money(10, 'EUR');     $what = $fiveEuros + $tenDollars; What would you expect to be in $what? A `BcMath\Nu

Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions

Hi On 4/4/24 23:27, Ilija Tovilo wrote: I think it would be reasonable to consider deprecating passing extra arguments to a non-variadic function. IIRC one of the bigger downsides of this change are closure calls that may provide arguments that the callee does not care about. […] The user ma

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

Hi On 4/5/24 02:20, Saki Takamachi wrote: In other words, the concerns we are currently aware of are issues of responsibility on the user's side, and my opinion is that there is no need to give that much consideration. However, this is my personal opinion, and there may be more reasonable opi

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

Hi On 4/4/24 02:54, Jordan LeDoux 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 confusing to users and sh

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

Hi Tim, > Can you please clean up the RFC text? I find the “Updated X/X” bits > confusing, because I'm not sure whether this is what the RFC is going to > propose, or whether this is something that was superseded by the following > discussion. > > The Wiki already provides a version history sh

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

Hi [cleaning out CC list] On 4/4/24 08:29, Saki Takamachi wrote: 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_

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

Hi Barney, > Ah ok. Maybe that's the standard way internal classes are written, and we can > consider it generally an error for a child class to override the constructor > without calling `parent::__construct()`. I know tools warn users not to > forget the parent call. Thanks, A fallback would

Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions

Le 04/04/2024 à 23:38, Mark Trapp a écrit : On Thu, Apr 4, 2024 at 2:16 PM Bilge wrote: On 04/04/2024 16:57, Tim Düsterhus wrote: I think it would be reasonable to consider deprecating passing extra arguments to a non-variadic function. This seems like the only reasonable thing to do, to me.