Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
On 27.03.2024 01:36, Saki Takamachi wrote:
On the other hand, if allow the calculation method to specify a scale, we can
write it like this:
```
$num = new Number('1.23');
$num2 = new Number('4.56');
$result = $num->add($num2, 4);
$result->value; // '5.7900'
$result->scale; // 4
```
It's just one less line, but that's the only reason to support the `$scale`
argument.
If you write it as:
$result = $num->withScale(4)->add($num2);
it's not an extra line anymore. I also think that withScale() use will
be rare, as we have the scale in constructor.
I think the intention is more clear here, and I think it applies to all
cases you mentioned, including div or pow. If you know you need to
change the scale just add ->withScale(X) before.
--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
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 have known about grapheme_*, but I > didn't. Oh my, the manual says since PHP 5.3 no less. From what I've seen > around being used, I'm far from the only one though. In an attempt to justify > my own stupidity I searched its use and it's bad. > > Searching on github with language:PHP: > `mb_strlen` 84k files, `grapheme_strlen` 680 > > Then a big number of first 100 of these files are stubs/polyfills/phpstan > metadata. I've seen no framework except Symphony (but they might be further > in the searchresults) > > The grapheme_str_split function, as well as other intl extension functions is > what should replace mbstring really. > > > YES! > > I'm sorry to have wasted your time. If you need someone to help for the > grapheme_ marketing team, let me know. Hi, Casper I think still useful mbstring functions. Because mbstring functions is still valid as a bridge to non-Unicode character codes. We think it makes sense for mbstring to calculate in Unicode code point units. Therefore, I think make sense that separate mbstring functions and grapheme functions. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 developer the choice of having it throw if the value is > outside the range of floats or return INF or -INF, > or possibly the user should just check for infinite values themselves. I was thinking about those features too. However, I'm concerned that proposing too many features will complicate the RFC and make it difficult to get it approved. It might make sense to have a second vote on whether to implement those features. Regards. Saki
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 $scale = null): BcNum {}
> public function sqrt(?int $scale = null): BcNum {}
>
> I'd suggest:
>
> public function add(BcNum|string|int $num): BcNum {}
> public function sqrt(): BcNum {}
>
> but I have no clue about BCMath.
Yeah, you're right. By using `withScale` before calculating, we can obtain
results of arbitrary precision without using Scale during calculation.
The code in that case would look like this:
```
$num = new Number('1.23');
$num2 = new Number('4.56');
$numRescaled = $num->withScale(4);
$result = $numRescaled->add($num2);
$result->value; // '5.7900'
$result->scale; // 4
```
On the other hand, if allow the calculation method to specify a scale, we can
write it like this:
```
$num = new Number('1.23');
$num2 = new Number('4.56');
$result = $num->add($num2, 4);
$result->value; // '5.7900'
$result->scale; // 4
```
It's just one less line, but that's the only reason to support the `$scale`
argument.
However, for calculations other than mul and div, the calculation results will
always fit within the scale.
```
$num = new Number('1.23'); // scale 2
$num2 = new Number('1'); // scale 0
$num->add($num2); // '2.23', scale 2 is enough
$num->sub($num2); // '0.23', scale 2 is enough
$num->mod($num2); // '0.23', scale 2 is enough
```
On the other hand, for mul, div, and pow, the original `$num` scale may not be
enough.
```
$num = new Number('1.23'); // scale 2
$num2 = new Number('1.1'); // scale 1
$num->mul($num2); // '1.353' be '1.35', scale 2 is not enough
```
```
$num = new Number('1.23'); // scale 2
$num2 = new Number('4'); // scale 0
$num->div($num2); // '0.3075' be '0.30', scale 2 is not enough
$num->pow($num2); // '2.28886641', be '2.28' scale 2 is not enough
```
For mul and pow, can calculate the required scale. However, for div, the
calculation may never end, such as `0.3`, so it is not possible to
calculate the scale to fit the result completely.
In cases like this, we thought that some users would want to easily specify the
scale, so we created an easy-to-use signature.
However, it may not be necessary to specify scale for all calculation
functions. Is it reasonable to specify only mul, div, pow, or only div?
Regards.
Saki
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 it *should* have "BC" is that it comes from "Basic
> Calculator" (https://www.php.net/manual/en/book.bc.php#118203)
I re-read the namespace RFC again. I also re-read the RFC regarding class
naming conventions.
https://wiki.php.net/rfc/namespaces_in_bundled_extensions
https://wiki.php.net/rfc/class-naming
There's no need for the namespace to follow class naming conventions, but the
acronym doesn't seem to need to be pascal-case anyway (I remembered it
incorrectly). However, the RFC states that the extension's namespace must match
the extension name, so it seems correct in this case for the namespace to be
`BCMath`.
And indeed, looking at the example in the namespace RFC, `BCMath\Number` might
be appropriate in this case (I think I was sleepy yesterday).
I changed `BcNum` to `BCMath\Number` in my RFC.
> - Should ->value rather be ->toString() ? ->value alone doesn't really
> say much. I'm on the fence here though, as there is already
> (internally) a ->__toString() method to make the (string) cast work.
What is the main difference between getting a read-only property with `->value`
and getting the value using a method?
> - Would it make sense to have "floor" and "ceil" to also have a scale,
> or precision? Or would developers instead have to use "round" in that
> case?
> - Which rounding modes are supported with "round", the same ones as the
> normal round() function?
`bcfloor` and `bcceil` originally have no scale specification. This is because
the result is always a string representing an integer value. And since the
supported round-mode is the same as standard-round, `ROUND_FLOOR` and
`ROUND_CEILING` are also supported.
Therefore, if want to obtain floor or ceil behavior with a specified scale, I
recommend specifying the mode as round.
> - In this example, what would $result->scale show? (Perhaps add that to
> the example?):
>
> $num = new BcNum('1.23', 2);
> $result = $num + '1.23456';
> $result->value; // '2.46456'
> $result->scale; // ??
In this case, `$result->scale` will be `'5'`. I added this to the RFC.
> - Exceptions
>
> The RFC does not mention which exceptions can be thrown. Is it just
> the one? It might be beneficial to *do* have a new exception
> hierarchy.
As far as I know right now, following exceptions can be thrown:
- Value error when a string that is invalid as a number is used in a
constructor, calculation method, or operation
- Divide by 0 error (include Modulo by zero)
I was thinking that it would be a bad idea to increase the number of classes
without thinking, and was planning to use general exceptions, but would it be
better to use dedicated exceptions?
By the way, generally when implementing such exceptions in userland, value
errors and divide-by-zero errors are probably defined as separate classes, but
should they be separated in this case?
Regards.
Saki
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
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
> "peculiarities", but an idea occurred to me that may have some
> advantages, so here goes:
>
> Use the "set" keyword that you've already introduced to set the raw
> value of a "backed" property:
>
> public int $name {
> set {
> set strtoupper($value);
> }
> }
> Or when used in short form:
>
> public int $name {
> set => set strtoupper($value);
> }
>
> Advantages in no particular order:
> 1. Shorter than $this->name
> 2. No magic $field
> 3. Short and long form works the same
>
> Disadvantage: "Set" can only be used to set the raw value inside the
> hook method itself. Or maybe that's a good thing too. To be honest, I
> don't love that $this->name sometimes goes through the hook and
> sometimes not. I'd prefer if the raw value could only be accessed
> inside the hooks or via a special syntax like f.ex. $this->name:raw
>
> If there are any use cases or technical details that I've missed that
> would make this syntax unfavourable, I apologize.
Interesting idea. Not being able to write the raw value except in the set hook
isn't a bug, but an important feature, so that's not a downside. (Modulo
reflection, which is a reasonable back-door.)
However, there's a few other disadvantages that probably make it not worth it.
1. `set` is not actually a keyword at the moment. It's contextually parsed in
the lexer, so it doesn't preclude using `set` as a constant or function name
the way a full keyword does. (PHP has many of these context-only keywords.)
Making it a keyword inside the body of the hook would do that, however.
2. Like $field, it would be a syntax you just "have to know". Most people seem
to hate that idea, right or wrong.
3. Like the considered syntaxes for parent-access, it wouldn't be possible to
do anything but a direct write. So `set => set++` wouldn't be possible,
whereas with $this->prop all existing operations should "just work."
4. Would we then also want a `get` keyword in the get hook to be parallel?
What does that even do there? It would have the same implications as point 3
in get, so we're back to $field by a different spelling.
So it's an interesting concept, but the knock-on effects would lead to a lot
more complications.
> Another observation (I apologize for being late to the game but it was
> a long RFC and thread to read through):
>
> What would happen if we stopped talking about virtual vs. backed
> properties? Couldn't we just treat a property that was never set the
> same as any other uninitialized property?
> What I mean is, that if you try to access the raw value of a property
> with a set hook that never sets its own raw value, you'd get either
> null or Typed property [...] must not be accessed before
> initialization, just like you'd expect if you're already used to modern
> php. Of course you'd just write your code correctly so that that never
> happens. It's already the case that uninitialized properties are
> omitted when serializing the object so there would be no difference
> there either.
>
> The advantage here would be that there's no need to detect the virtual
> or backed nature of the property at compile time and the RFC would be a
> lot shorter.
Unfortunately the backed-vs-virtual distinction is quite important at an
implementation level for a few reasons.
1. A backed property reserves memory space for that property. A virtual
property does not. Making virtual properties "unused backed" properties would
increase memory usage for values that would never be usable.
2. There would be no realistic way to differentiate between a get-only virtual
property with no storage, and a backed property that just happens to have a get
hook but no set hook. Meaning you would be able to write to an
otherwise-inaccessible backing value of the property.
3. That would then appear in serialization, even though it's impossible to get
to from code without using reflection. Which is just all kinds of confusing.
So for practical reasons, the distinction isn't just a user-facing difference
but an important engine-level distinction we cannot avoid.
Cheers.
--Larry Garfield
Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
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, the manual says since PHP 5.3 no less. From what I've seen around being used, I'm far from the only one though. In an attempt to justify my own stupidity I searched its use and it's bad. Searching on github with language:PHP: `mb_strlen` 84k files, `grapheme_strlen` 680 Then a big number of first 100 of these files are stubs/polyfills/phpstan metadata. I've seen no framework except Symphony (but they might be further in the searchresults) > The grapheme_str_split function, as well as other intl extension functions is > what should replace mbstring really. YES! I'm sorry to have wasted your time. If you need someone to help for the grapheme_ marketing team, let me know.
Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
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 more
> robust, and we were able to squish the last remaining edge cases.
>
> Baring any major changes, we plan to bring this to a vote in mid-March.
>
> It’s long, but that’s because we’re handling every edge case we could
> think of. Properties involve dealing with both references and inheritance,
> both of which have complex implications. We believe we’ve identified the
> most logical handling for all cases, though.
>
> Note the FAQ question at the end, which explains some design choices.
>
> There’s one outstanding question, which is slightly painful to ask:
> Originally, this RFC was called “property accessors,” which is the
> terminology used by most languages. During early development, when we had
> 4 accessors like Swift, we changed the name to “hooks” to better indicate
> that one was “hooking into” the property lifecycle. However, later
> refinement brought it back down to 2 operations, get and set. That makes
> the “hooks” name less applicable, and inconsistent with what other
> languages call it.
>
> However, changing it back at this point would be a non-small amount of
> grunt work. There would be no functional changes from doing so, but it’s
> lots of renaming things both in the PR and the RFC. We are willing to do so
> if the consensus is that it would be beneficial, but want to ask before
> putting in the effort.
>
> --
> Larry Garfield
> la...@garfieldtech.com
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
"peculiarities", but an idea occurred to me that may have some advantages,
so here goes:
Use the "set" keyword that you've already introduced to set the raw value
of a "backed" property:
public int $name {
set {
set strtoupper($value);
}
}
Or when used in short form:
public int $name {
set => set strtoupper($value);
}
Advantages in no particular order:
1. Shorter than $this->name
2. No magic $field
3. Short and long form works the same
Disadvantage: "Set" can only be used to set the raw value inside the hook
method itself. Or maybe that's a good thing too. To be honest, I don't love
that $this->name sometimes goes through the hook and sometimes not. I'd
prefer if the raw value could only be accessed inside the hooks or via a
special syntax like f.ex. $this->name:raw
If there are any use cases or technical details that I've missed that would
make this syntax unfavourable, I apologize.
Another observation (I apologize for being late to the game but it was a
long RFC and thread to read through):
What would happen if we stopped talking about virtual vs. backed
properties? Couldn't we just treat a property that was never set the same
as any other uninitialized property?
What I mean is, that if you try to access the raw value of a property with
a set hook that never sets its own raw value, you'd get either null or Typed
property [...] must not be accessed before initialization, just like you'd
expect if you're already used to modern php. Of course you'd just write
your code correctly so that that never happens. It's already the case that
uninitialized properties are omitted when serializing the object so there
would be no difference there either.
The advantage here would be that there's no need to detect the virtual or
backed nature of the property at compile time and the RFC would be a lot
shorter.
Thank you for your consideration!
Best,
Jakob
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 outside the range of possible ints. For toFloat it might be nice to have a flag argument to give the developer the choice of having it throw if the value is outside the range of floats or return INF or -INF, or possibly the user should just check for infinite values themselves.
Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
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
>preg_match_all('/\X/u', ...). The result of this method in my opinion is not
>very usefull by itself. I've done some searching on various code platforms
>where I mostly find the use-case for counting the number of grapheme's. I've
>used it to implement strrev() that correctly works multibyte.
>
>I'm very sad that mbstring works on codepoints instead of grapheme's and I
>would very much like to see something happening in that area, but I think
>expanding a simple string to an array of as many elements to give developers a
>tool to do this in PHP-space is not good enough. Especially since it can
>already be achieved with a regexp that already works.
>
>In my opinion: This adds nothing, and tells the PHP developer that is ok to do
>count(grapheme_str_split()) for a more accurate mb_strlen().
>
>I would like to see a family of functions that can do multibyte str_split(),
>strrev(), substr(). Ideally as bugfix in mb_* functions, because the edge-case
>of wanting to know the length in codepoints of a string is a weird edge-case.
>No developer wants to know that. mb_strlen() should have returned the number
>of graphemes from the start.
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.
The intl extension is also built on ICU, an actual unicode text processing
library.
The grapheme_str_split function, as well as other intl extension functions is
what should replace mbstring really.
cheers
Derick
Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
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 done some searching on various code platforms
where I mostly find the use-case for counting the number of grapheme's. I've
used it to implement strrev() that correctly works multibyte.
I'm very sad that mbstring works on codepoints instead of grapheme's and I
would very much like to see something happening in that area, but I think
expanding a simple string to an array of as many elements to give developers a
tool to do this in PHP-space is not good enough. Especially since it can
already be achieved with a regexp that already works.
In my opinion: This adds nothing, and tells the PHP developer that is ok to do
count(grapheme_str_split()) for a more accurate mb_strlen().
I would like to see a family of functions that can do multibyte str_split(),
strrev(), substr(). Ideally as bugfix in mb_* functions, because the edge-case
of wanting to know the length in codepoints of a string is a weird edge-case.
No developer wants to know that. mb_strlen() should have returned the number of
graphemes from the start.
On Tue, Mar 26, 2024, at 01:44, youkidearitai wrote:
> 2024年3月26日(火) 5:43 David CARLIER :
> >
> > I second this, I think it is a good addition which makes a lot of sense.
> >
> > Cheers.
> >
> > On Mon, 25 Mar 2024 at 20:36, Ayesh Karunaratne wrote:
> >>
> >> >
> >> > 2024年3月9日(土) 15:26 youkidearitai :
> >> > >
> >> > > Hello, Internals
> >> > >
> >> > > I created an wiki for `grapheme_str_split` function.
> >> > > Please see:
> >> > > https://wiki.php.net/rfc/grapheme_str_split
> >> > >
> >> > > I would like to "Under Discussion" section.
> >> > >
> >> > > Best Regards
> >> > > Yuya
> >> > >
> >> > > --
> >> > > ---
> >> > > Yuya Hamada (tekimen)
> >> > > - https://tekitoh-memdhoi.info
> >> > > - https://github.com/youkidearitai
> >> > > -
> >> >
> >> > Hello, Internals
> >> >
> >> > I want to go to "Voting" phase if nothing any comment.
> >> > I will start at tomorrow(26th) to "Voting" phase.
> >> >
> >> > Thank you
> >> > Yuya
> >> >
> >> > --
> >> > ---
> >> > Yuya Hamada (tekimen)
> >> > - https://tekitoh-memdhoi.info
> >> > - https://github.com/youkidearitai
> >> > -
> >>
> >> I think it makes sense to add this function, and the PR worked well
> >> too; It correctly split individual graphemes for all comlex Emojis,
> >> ZWJs, and those Cthulu texts, and everything else I threw at it.
> >>
> >> Good luck for the RFC vote today, hope it passes 🤞.
>
>
> Hi, Internals
>
> grapheme_str_split going to "Voting" phase.
> Vote end is 10th April 00:00 GMT
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
>
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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
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 $scale = null): BcNum {}
public function sqrt(?int $scale = null): BcNum {}
I'd suggest:
public function add(BcNum|string|int $num): BcNum {}
public function sqrt(): BcNum {}
but I have no clue about BCMath.
--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 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 it *should* have "BC" is that it comes from "Basic Calculator" (https://www.php.net/manual/en/book.bc.php#118203) - Should ->value rather be ->toString() ? ->value alone doesn't really say much. I'm on the fence here though, as there is already (internally) a ->__toString() method to make the (string) cast work. - Would it make sense to have "floor" and "ceil" to also have a scale, or precision? Or would developers instead have to use "round" in that case? - Which rounding modes are supported with "round", the same ones as the normal round() function? - In this example, what would $result->scale show? (Perhaps add that to the example?): value; // '2.46456' $result->scale; // ?? - Exceptions The RFC does not mention which exceptions can be thrown. Is it just the one? It might be beneficial to *do* have a new exception hierarchy. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
Hi, I wrote in my RFC that it does not support global settings. Regards. Saki
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 reason to use global settings other than "they exist in existing implementations"… Okay, regarding the existing global setting, I decided not to support it with BcNum. Regards. Saki
Re: [PHP-DEV][RFC][Vote] grapheme_cluster for str_split, grapheme_str_split function
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 > > > > -- > > --- > > Yuya Hamada (tekimen) > > - https://tekitoh-memdhoi.info > > - https://github.com/youkidearitai > > - > > And a link is this one for those wondering where to click: > https://wiki.php.net/rfc/grapheme_str_split Thank you very much, Peter. I forgot link. Thanks again. Regards Yuya -- --- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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
>> ```
>>
>>
>> Maybe also worth providing a way to specify that all decimals should be
>> printed, instead of just a fixed number of decimals.
>
> Ah I see! It sounds exactly like `number_format`. Sure, this might make
> sense. To me, this seems worth supporting.
>
>
> BTW,
> ```
> $bcNum = new BcNum('1234567890123456789.23456789’);
> ```
>
> When I saw this, I thought that the behavior when $scale is omitted is
> that in addition to the option of "using the global setting value",
> there is also the option of "counting the length of `$num` and storing
> all `$num`”. In other words, it does not use any global settings.
>
> Which of these do you think is better?
Global mode settings are an anti-pattern in most cases. Please avoid those
whenever possible, as they lead to unpredictable behavior.
--Larry Garfield
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 the namespace ("BcMath" is appropriate instead of "BCMath" as it
must follow PHP naming conventions).
What concerns me is that the symbol "Number" is difficult to understand in the
code. So, how about "BcMath\BcNum”?
Regards.
Saki
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 `new Number()`, which is likely to conflict with existing code. In fact, if take a look at GitHub Code Search, you'll find 3.2k results. https://github.com/search?type=code&auto_enroll=true&q=%22new+Number%28%22+language%3APHP+ This won't result in a BC Break, but it can be a bit difficult to use. 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. -- Aleksander Machniak Kolab Groupware Developer[https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 with existing code. In fact, if take a look at GitHub Code Search, you'll find 3.2k results. https://github.com/search?type=code&auto_enroll=true&q=%22new+Number%28%22+language%3APHP+ This won't result in a BC Break, but it can be a bit difficult to use. > ps. there's '2,111' in one place, but should be '2.111', I guess. Oops, thank you. You have good eyes. Regards. Saki
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 '2.111', I guess. -- Aleksander Machniak Kolab Groupware Developer[https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
Re: [PHP-DEV][RFC][Vote] grapheme_cluster for str_split, grapheme_str_split function
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) > - https://tekitoh-memdhoi.info > - https://github.com/youkidearitai > - And a link is this one for those wondering where to click: https://wiki.php.net/rfc/grapheme_str_split
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 should be
> printed, instead of just a fixed number of decimals.
Ah I see! It sounds exactly like `number_format`. Sure, this might make sense.
To me, this seems worth supporting.
BTW,
```
$bcNum = new BcNum('1234567890123456789.23456789’);
```
When I saw this, I thought that the behavior when $scale is omitted is that in
addition to the option of "using the global setting value", there is also the
option of "counting the length of `$num` and storing all `$num`”. In other
words, it does not use any global settings.
Which of these do you think is better?
Regards.
Saki
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 avoid the need to lose precision by
converting to float first.
I came up with the following code, is it close to what you intended?
```
$num = BcNum::fromNumberFormat(1.2345, 5);
$num->value; // 1.23450
```
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 should be
printed, instead of just a fixed number of decimals.
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 readonly > property? I had completely forgotten about the existence of read-only properties. That makes sense. > I suggest renaming `setScale` to `withScale`. Although the docs will make > clear that the object is immutable, `set` is associated with mutation and > might be confusing. `with` is not as well known as a prefix but is associated > with immutable objects. Indeed, I felt uncomfortable using "set”. I didn't know that "with" was related to immutable. **I immediately reflected the above two points in my RFC** :D > 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 avoid the need to lose precision by converting to float first. I came up with the following code, is it close to what you intended? ``` $num = BcNum::fromNumberFormat(1.2345, 5); $num->value; // 1.23450 ``` Regards. Saki
Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
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 the existing number_format function, but would avoid the need to lose precision by converting to float first.
