[PHP-DEV] [RFC idea introduce] The issue where the __callStatic magic method is not called when statically calling a public method.

[하늘아부지]

Hi.

I would like to register an RFC on the following issue.
https://github.com/php/php-src/issues/13813

To summarize briefly, users expect that the `__callStatic` magic method
will be called in all cases when a method is not static while using the
`__callStatic`. However, in reality, if the method is public, the
`__callStatic` magic method is not called, and an error still occurs.

I would like to hear your opinions.
I also hope someone can help with the RFC registration.




```php

Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function

[Rowan Tommins [IMSoP]]

On 26/03/2024 21:14, Casper Langemeijer wrote:

If you need someone to help for the grapheme_ marketing team, let me know.


I think a big part of the problem is that very few people dig into the 
complexities of text encoding, and so don't know that a "grapheme" is 
what they're looking for.


Unicode documentation is, generally, very careful with its terminology - 
distinguishing between "code points", "code units" "graphemes" , 
"grapheme clusters", "glyphs", etc. Pretty much everyone else just says 
"character", and assumes that everyone knows what they mean.



As a case in point, looking at the PHP manual pages for strlen, 
mb_strlen, and grapheme_strlen:


Short summary:

- strlen — Get string length
- mb_strlen — Get string length
- grapheme_strlen — Get string length in grapheme units

Description:

- Returns the length of the given string.
- Gets the length of a string.
- Get string length in grapheme units (not bytes or characters)


The first two don't actually say what units they're measuring in. Maybe 
it's millimetres? ;)


The last one uses the term "grapheme" without explaining what it means, 
and makes a contrast with "characters", which is confusing, as one of 
the definitions in the Unicode glossary 
[https://unicode.org/glossary/#grapheme] is:


> What a user thinks of as a character.


The mb_strlen documentation has a bit more explanation in its Return 
Values section:


> Returns the number of characters in string string having character 
encoding encoding. A multi-byte character is counted as 1.


For Unicode in particular, this is a poor description; it is completely 
missing the term "code point", which is what it actually counts.


That's probably because ext/mbstring wasn't written with Unicode in 
mind, it was "developed to handle Japanese characters", back in 2001; 
and it still does support several pre-Unicode "multi-byte encodings". 
For a bit of nostalgia: 
http://web.archive.org/web/20010605075550/http://www.php.net/manual/en/ref.mbstring.php



So... if you want to help make people more aware of the grapheme_* 
functions, one place to start would be editing the documentation for the 
various string, mbstring, and grapheme functions to use consistent 
terminology, and sign-post each other more clearly. 
http://doc.php.net/tutorial/



Regards,

--
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] GitHub milestones

[Ilija Tovilo]

Hi Jakub

On Wed, Mar 27, 2024 at 4:55 PM Jakub Zelenka  wrote:
>
> We actually decided not to do it for 8.3 because it would be just waste of 
> time to set all PR's with that milestone. The thing is that PR should just 
> get merged when it's ready and we won't be delaying release because some PR's 
> in that milestone are not ready so it does not have any meaning.

Thank you, I was unaware that this was a conscious decision. I agree
that it's not particularly useful for the next minor version. If they
are ready, nothing is blocking a merge to master.

> I'm not really sure if there's any point to have non-draft PR's targeting 
> next major version because they cannot be merged to master until it is 
> decided the next version will be the major one. So those PR's should be draft 
> but it might make sense to create milestone for them to show quickly why they 
> are in draft.

Draft PRs that target the next major version can make sense if they
are part of an RFC. I generally believe that every RFC should have at
least a proof-of-concept. In my experience, the implementation is the
only reliable way to reveal conceptual issues.

But then again, such RFCs should be in the RFC listing, as mentioned
in my previous message. So I agree that there's not a big need to
milestones.

> So I don't think there is much point in adding 8.4 milestone but 9.0 might be 
> useful.

That sounds reasonable to me, as it shouldn't cost much. Milestones
don't need to be complete either, it can be added where it makes
sense, for things that might be forgotten otherwise.

Ilija

Re: [PHP-DEV] Request for RFC karma

[Ilija Tovilo]

Hi!

On Wed, Mar 27, 2024 at 12:59 PM 하늘아부지  wrote:
>
> I request RFC karma to discuss the issue at this link.
> https://github.com/php/php-src/issues/13813
>
> Wiki account : daddyofsky

Either somebody beat me to it, or you already had RFC privileges.

Note that step 1 in the RFC process suggests introducing the RFC idea
to the mailing list first. This way, you can get an initial feel
whether your idea is desired by other developers, and thus whether
it's worth your time.

Good luck with the RFC!

Ilija

Re: [PHP-DEV] GitHub milestones

[Jakub Zelenka]

Hi,

On Wed, Mar 27, 2024 at 3:26 PM Ilija Tovilo  wrote:

> Hi Peter
>
> On Wed, Mar 27, 2024 at 9:44 AM Peter Kokot  wrote:
> >
> > I was wondering if it would be useful to add GitHub milestones for the
> PHP-8.4 and PHP-9.0 (or PHP-next or something like this)?
> > https://github.com/php/php-src/milestones
> >
> > Because some pull requests might target versions after the PHP-8.4 and
> it might be useful to have them additionally sorted to not forget about
> them. Not to tag all PRs of course but only those which are meant to go
> into some of the future branches.
>
> Milestones have already been used in the past
> (https://github.com/php/php-snilrc/milestones?state=closed
> ), so there's
> no reason not to do the same for 8.4 and 9.0. Most likely, we just
> forgot. It's probably not documented as part of the release process.
>
>
We actually decided not to do it for 8.3 because it would be just waste of
time to set all PR's with that milestone. The thing is that PR should just
get merged when it's ready and we won't be delaying release because some
PR's in that milestone are not ready so it does not have any meaning.

I'm not really sure if there's any point to have non-draft PR's targeting
next major version because they cannot be merged to master until it is
decided the next version will be the major one. So those PR's should be
draft but it might make sense to create milestone for them to show quickly
why they are in draft.

So I don't think there is much point in adding 8.4 milestone but 9.0 might
be useful.

Regards

Jakub

Re: [PHP-DEV] GitHub milestones

[Ilija Tovilo]

Hi Peter

On Wed, Mar 27, 2024 at 9:44 AM Peter Kokot  wrote:
>
> I was wondering if it would be useful to add GitHub milestones for the 
> PHP-8.4 and PHP-9.0 (or PHP-next or something like this)?
> https://github.com/php/php-src/milestones
>
> Because some pull requests might target versions after the PHP-8.4 and it 
> might be useful to have them additionally sorted to not forget about them. 
> Not to tag all PRs of course but only those which are meant to go into some 
> of the future branches.

Milestones have already been used in the past
(https://github.com/php/php-src/milestones?state=closed), so there's
no reason not to do the same for 8.4 and 9.0. Most likely, we just
forgot. It's probably not documented as part of the release process.

RFCs that have actionable tasks for the next major version should be
listed under "Pending Implementation / Landing" on the RFC page:
https://wiki.php.net/rfc#pending_implementationlanding

Adding them to a GitHub Milestone would make it a bit more explicit.
As for PRs that don't have an RFC, adding them to a milestone
definitely makes sense. However, PRs that may only be merged in the
next major version, and _don't_ require an RFC are extremely rare.

Ilija

[PHP-DEV] Request for RFC karma

[하늘아부지]

Hi.

I request RFC karma to discuss the issue at this link.
https://github.com/php/php-src/issues/13813

Wiki account : daddyofsky

Regards.

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

[Saki Takamachi]

Hi Aleksander,

> 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.

Ah, that's right. I wonder why I forgot about method chaining. Update RFC. If 
we miss something and $scale is needed, I can always revert the RFC.


> I'm not sure I like this. Maybe we should be more strict here and treat the 
> $scale in constructor (and later withScale()) as the actual scale for all 
> operations.
> 
> So, in the case above I'd expect ->scale to be 2, and ->value to be '2.46'. 
> If I wanted $num to have a scale that may change, I'd not define it in the 
> first place. Does that make sense?
> 
> ps. that also means withScale(null) should be possible.

I see, that may indeed make sense. Now here we have three choices about it. In 
fact, if want to behave like the current RFC, we can do it by calculating as 
`$num + new Number($str)`.
Yeah, I'll fix the RFC for this.

Regards.

Saki

[PHP-DEV] GitHub milestones

[Peter Kokot]

Hello,

I was wondering if it would be useful to add GitHub milestones for the
PHP-8.4 and PHP-9.0 (or PHP-next or something like this)?
https://github.com/php/php-src/milestones

Because some pull requests might target versions after the PHP-8.4 and it
might be useful to have them additionally sorted to not forget about them.
Not to tag all PRs of course but only those which are meant to go into some
of the future branches.

Thanks.

Re: [PHP-DEV] base64_encode without padding

[Remi Collet]

Le 13/03/2024 à 17:06, Remi Collet a écrit :


   PHPAPI extern zend_string *php_base64_encode_ex
     (const unsigned char *, size_t, zend_long flags);


This is done in master

No change in user-land
and no plan from me.


Remi

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

[Aleksander Machniak]

On 27.03.2024 01:03, Saki Takamachi wrote:

$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.


I'm not sure I like this. Maybe we should be more strict here and treat 
the $scale in constructor (and later withScale()) as the actual scale 
for all operations.


So, in the case above I'd expect ->scale to be 2, and ->value to be 
'2.46'. If I wanted $num to have a scale that may change, I'd not define 
it in the first place. Does that make sense?


ps. that also means withScale(null) should be possible.

--
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

[Aleksander Machniak]

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