2024年3月27日(水) 6:18 Casper Langemeijer :
>
> On Tue, Mar 26, 2024, at 18:15, Derick Rethans wrote:
>
> Many of these already exist, such as grapheme_substr. We can't simply change
> the behaviour of the already existing functions due to BC reasons.
>
>
> Wow. I feel very stupid. I feel I should
Hi Barney,
> 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 flag
> argument to give the
Hi Derick,
I made one mistake.
> In this case, `$result->scale` will be `'5'`. I added this to the RFC.
It's `5`, not `'5’`.
Regards.
Saki
Hi Aleksander,
> Here's another question.
>
> 1. Since we have withScale(), do we need to inherit the $scale argument from
> the functional API? Can't we derive it from the object the method is being
> invoked on?
>
> So, instead, e.g.
>
> public function add(BcNum|string|int $num, ?int
Hi Derick,
> - You've picked as class name "BcNum". Following
> our naming guidelines, that probably should be \BCMath\Num (or
> \BC\Num, but that is less descriptive):
>
> https://github.com/php/policies/blob/main/coding-standards-and-naming.rst#namespaces-in-extensions
>
> The reason
On Tue, Mar 26, 2024, at 8:18 PM, Jakob Givoni wrote:
> Hi, thanks for the RFC and the effort put into trying to make it
> palatable to skeptical minds!
>
> After reading most of the discussion in this thread I believe that the
> RFC in its current form can work and that I will get used to it's
On Tue, Mar 26, 2024, at 18:15, Derick Rethans wrote:
> Many of these already exist, such as grapheme_substr. We can't simply change
> the behaviour of the already existing functions due to BC reasons.
Wow. I feel very stupid. I feel I should have known about grapheme_*, but I
didn't. Oh my,
On Wed, Feb 21, 2024, 19:57 Larry Garfield wrote:
> Hello again, fine Internalians.
>
> After much on-again/off-again work, Ilija and I are back with a more
> polished property access hooks/interface properties RFC. It’s 99%
> unchanged from last summer; the PR is now essentially complete and
On 2024-03-24 13:13, Saki Takamachi wrote:
I want to start the discussion on the PHP RFC: Support object type in
BCMath.
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
On 26 March 2024 17:04:18 GMT, Casper Langemeijer wrote:
>I'd like to address an issue I have with this RFC.
Please don't top reply.
>I'm not sure is solves a problem by itself. If I understand all of this
>correctly this only does what already can be accomplished with
I'd like to address an issue I have with this RFC.
I'm not sure is solves a problem by itself. If I understand all of this
correctly this only does what already can be accomplished with
preg_match_all('/\X/u', ...). The result of this method in my opinion is not
very usefull by itself. I've
On 24.03.2024 14:13, Saki Takamachi wrote:
Hi internals,
I want to start the discussion on the PHP RFC: Support object type in BCMath.
https://wiki.php.net/rfc/support_object_type_in_bcmath
Here's another question.
1. Since we have withScale(), do we need to inherit the $scale argument
On Sun, 24 Mar 2024, Saki Takamachi wrote:
> Hi internals,
>
> I want to start the discussion on the PHP RFC: Support object type in BCMath.
>
> https://wiki.php.net/rfc/support_object_type_in_bcmath
I have some comments:
- You've picked as class name "BcNum". Following
our naming
Hi,
I wrote in my RFC that it does not support global settings.
Regards.
Saki
Hi Larry,
> Global mode settings are an anti-pattern in most cases. Please avoid those
> whenever possible, as they lead to unpredictable behavior.
Yes, that's right.
BCMath has an existing global setting, so I was wondering if it was something I
could ignore. But that means there's no
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 GMT
> >
> > Regards
> > Yuya
> >
> > --
> >
On Tue, Mar 26, 2024, at 12:50 PM, Saki Takamachi wrote:
> Hi Barney,
>
>> No, that's not quite what I meant - I meant more like the opposite:
>>
>>
>> ```
>> $bcNum = new BcNum('1234567890123456789.23456789');
>> echo $bcNum->format(8, '.', ',') // 1,234,567,890,123,456,789.23456789
>> ```
>>
Hi Aleksander,
> After reading https://wiki.php.net/rfc/namespaces_in_bundled_extensions again
> I see it is a perfect case to apply it. While it's not a must, I think we
> should go with BCMath/Number.
Thank you, I have read it now. Certainly in this case it makes sense to use
"BcMath" as
On 26.03.2024 14:35, Saki Takamachi wrote:
Hi Aleksander,
Was BCMath\Number considered instead of BcNum?
Yes, that was one of the candidates. However, as far as I know, there are no
examples of PHP internal classes having namespaces.
Also, if use a namespace, the code will be written as
Hi Aleksander,
> Was BCMath\Number considered instead of BcNum?
Yes, that was one of the candidates. However, as far as I know, there are no
examples of PHP internal classes having namespaces.
Also, if use a namespace, the code will be written as `new Number()`, which is
likely to conflict
On 24.03.2024 14:13, Saki Takamachi wrote:
Hi internals,
I want to start the discussion on the PHP RFC: Support object type in BCMath.
https://wiki.php.net/rfc/support_object_type_in_bcmath
Was BCMath\Number considered instead of BcNum?
ps. there's '2,111' in one place, but should be
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 GMT
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> -
Hi Barney,
> No, that's not quite what I meant - I meant more like the opposite:
>
>
> ```
> $bcNum = new BcNum('1234567890123456789.23456789');
> echo $bcNum->format(8, '.', ',') // 1,234,567,890,123,456,789.23456789
> ```
>
>
> Maybe also worth providing a way to specify that all decimals
On 2024-03-26 11:35, Saki Takamachi wrote:
**I immediately reflected the above two points in my RFC** :D
Thanks, looks good.
One more suggestion - might it be worth adding a `format` function
to the new BcNum class? This would be similar to the existing
number_format function, but would
Hi Barney, thanks for the points and suggestions!
> Is there any reason not to give the BcNum class a public readonly string
> `value` property? Would just save a few characters of typing to use value
> instead of getValue().
> Also as with the value, any reason not to make the scale a pubic
On 24/03/2024 13:13, Saki Takamachi wrote:
I want to start the discussion on the PHP RFC: Support object type in BCMath.
https://wiki.php.net/rfc/support_object_type_in_bcmath
One more suggestion - might it be worth adding a `format` function to
the new BcNum class? This would be similar to
26 matches
Mail list logo
