Hi Barney, Jordan,
I would like to thank you all again for discussing this RFC in great detail. I
believe that the specification for the `BCMath\Number` class is in very good
shape due to the detailed discussions and the great amount of feedback. Now
that we have been able to brush up the
On Thu, Apr 4, 2024 at 2:19 PM Barney Laurance
wrote:
>
> I don't think it will be possible to make a good Money class as a child of
> this. BcNum is a read-only class, so if the constructor of BcNum is final
> then the child class won't be able to take the currency as a constructor
> param, and
On Thu, Apr 4, 2024 at 2:28 PM Rowan Tommins [IMSoP]
wrote:
>
>
> I haven't followed the discussion in the other thread, but I'm not sure
> what the use case would be for a "fixed scale decimal" that followed
> those rules.
>
> As mentioned before, the use case I've encountered is money
>
On 03/04/2024 00:01, Ilija Tovilo wrote:
Data classes are classes with a single additional > zend_class_entry.ce_flags flag. So unless customized, they behave as
> classes. This way, we have the option to tweak any behavior we would
> like, but we don't need to. > > Of course, this will still
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. If this were the
> case, there
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.net/rfc/strict_argcount
>
> The RFC is 9 years old by now. My
On 04/04/2024 02:29, Jordan LeDoux wrote:
But when it comes to fixed-precision values, it should follow rules very
similar to those we discussed in the BCMath thread:
- Addition and subtraction should return a value that is the largest
scale/precision of any operands in the calculation.
-
On 04/04/2024 22:10, Jordan LeDoux wrote:
On Thu, Apr 4, 2024 at 1:59 PM Barney Laurance
wrote:
Hi again,
On 27/03/2024 00:40, Saki Takamachi wrote:
Do we also need `toFloat` and `toInt` functions? Seems like using explicit
functions will be safer than casting.
For
On 04/04/2024 01:54, Jordan LeDoux wrote:
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
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. If this were the
case, there should be no need for any new syntax, since we could simply
On Thu, Apr 4, 2024 at 1:59 PM Barney Laurance
wrote:
> Hi again,
>
> On 27/03/2024 00:40, Saki Takamachi wrote:
>
> Do we also need `toFloat` and `toInt` functions? Seems like using explicit
> functions will be safer than casting.
>
> For toInt I'd expect an exception if the value is outside
Le 04/04/2024 à 17:57, Tim Düsterhus a écrit :
Hi
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.net/rfc/strict_argcount
The RFC is 9 years old by now. My gut feeling is
Hi again,
On 27/03/2024 00:40, Saki Takamachi wrote:
Do we also need `toFloat` and `toInt` functions? Seems like using explicit
functions will be safer than casting.
For toInt I'd expect an exception if the value is outside the range of possible
ints. For toFloat it might be nice to have a
On Thu, Apr 4, 2024, at 3:49 PM, Tim Düsterhus wrote:
> Hi
>
> On 4/4/24 17:40, Vinicius Dias wrote:
>>> I like this concept, but instead of introducing a new syntax, have you
>>> considered leveraging attributes in the same way that PHP 8.3
>>> introduced #[Override]?
>>>
>>> #[Nonvariadic]
>>>
Hi
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.net/rfc/strict_argcount
The RFC is 9 years old by now. My gut feeling is be that using an actual
variadic parameter for
Hi
On 4/4/24 17:40, Vinicius Dias wrote:
I like this concept, but instead of introducing a new syntax, have you
considered leveraging attributes in the same way that PHP 8.3
introduced #[Override]?
#[Nonvariadic]
function foo () {}
foo(42); // warning: foo() expects exactly 0 arguments, 1
> Le 4 avr. 2024 à 01:08, Kamil Tekiela a écrit :
>
> If there are no more comments, I would like to put this RFC to vote in
> the next two days.
Hi,
1. In session_start(), it is possible to override ini settings like that:
```php
session_start([ 'use_cookies' => '1', 'use_only_cookies'
> I like this concept, but instead of introducing a new syntax, have you
> considered leveraging attributes in the same way that PHP 8.3
> introduced #[Override]?
>
> #[Nonvariadic]
> function foo () {}
> foo(42); // warning: foo() expects exactly 0 arguments, 1 given
>
> I think the intent would
> Le 4 avr. 2024 à 15:10, Kamil Tekiela a écrit :
>
> Why is passing extra arguments a problem at all?
In a parallel perfect and boring world, it is not a problem. In our world,
disallowing extra arguments have two advantages:
* catching bugs;
* allowing to add new optional parameters to an
Le 04/04/2024 à 16:29, Claude Pache a écrit :
Le 4 avr. 2024 à 15:03, Mark Trapp a écrit :
On Thu, Apr 4, 2024 at 5:43 AM Pablo Rauzy wrote:
I like this concept, but instead of introducing a new syntax, have you
considered leveraging attributes in the same way that PHP 8.3
introduced
> Le 4 avr. 2024 à 15:03, Mark Trapp a écrit :
>
> On Thu, Apr 4, 2024 at 5:43 AM Pablo Rauzy wrote:
>
> I like this concept, but instead of introducing a new syntax, have you
> considered leveraging attributes in the same way that PHP 8.3
> introduced #[Override]?
>
> #[Nonvariadic]
>
Le 04/04/2024 à 15:03, Mark Trapp a écrit :
On Thu, Apr 4, 2024 at 5:43 AM Pablo Rauzy wrote:
Hello all,
First, I'm new here, so let me start by warmly thanking everyone
involved in PHP development. I've started programming 22 years using it
as my first programming language, and still enjoy
Hello Kamil,
Le 04/04/2024 à 15:10, Kamil Tekiela a écrit :
Interesting proposal, but immediately I have two questions:
1. Why is passing extra arguments a problem at all? Is generating a
warning a good idea? If you would like to introduce a new syntax to
enforce non-variadic functions,
Hi Pablo,
Interesting proposal, but immediately I have two questions:
1. Why is passing extra arguments a problem at all? Is generating a
warning a good idea? If you would like to introduce a new syntax to
enforce non-variadic functions, shouldn't it be a runtime error then?
Generating a warning
On Thu, Apr 4, 2024 at 5:43 AM Pablo Rauzy wrote:
>
> Hello all,
>
> First, I'm new here, so let me start by warmly thanking everyone
> involved in PHP development. I've started programming 22 years using it
> as my first programming language, and still enjoy using it a lot :).
>
> I've read the
Hello all,
First, I'm new here, so let me start by warmly thanking everyone
involved in PHP development. I've started programming 22 years using it
as my first programming language, and still enjoy using it a lot :).
I've read the rfc:howto and the first step is to get feedback from this
Data classes will be a very useful addition to "API Platform".
API Platform is a "resource-oriented" framework that strongly encourages
the use of "data-only" classes:
we use PHP classes both as a specification language to document the public
shape of web APIs (like an OpenAPI specification, but
Hi Chris,
> Looks very promising!
>
> The default value for rounding is PHP_ROUND_TOWARD_ZERO. Is this because it
> is the same as the BCMath functions for consistency only or do you expect
> this to be the most used rounding mode?
> I didn't find any discussion about this choice, sorry if I
Am 04.04.2024 um 08:29 schrieb Saki Takamachi :
> 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.
>
>
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
30 matches
Mail list logo
