Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO

[Kentaro Takeda via internals]

Hi Saki,

Aside from a few concerns, I think your proposal is very sensible.

I have long felt a disconnect that while we have `beginTransaction()`,
`commit()`, and `rollback()` methods, there's no equivalent
functionality for `SAVEPOINT` in PDO. It seems natural to support
these commonly used transactional features as part of PDO's
functionality.

Having consistent support through PDO would be greatly appreciated
from a user perspective, but I do have concerns regarding the
variations in SQL. The following code is quoted from Laravel:

https://github.com/laravel/framework/blob/v10.43.0/src/Illuminate/Database/Query/Grammars/Grammar.php#L1307-L1310

```php
return 'SAVEPOINT '.$name;
```

While most databases use `SAVEPOINT [name]`, but:

https://github.com/laravel/framework/blob/v10.43.0/src/Illuminate/Database/Query/Grammars/SqlServerGrammar.php#L453-L456

```php
return 'SAVE TRANSACTION '.$name;
```

SQL Server uniquely uses `SAVE TRANSACTION [name]`. There might be
other variations in databases, so full support could be challenging,
which is something to be mindful of.

> change the signature of `rollback()` to `rollback(?string $name = null)`.

This might lead to confusion due to `rollback()` having multiple
functionalities, as `ROLLBACK` and `ROLLBACK TO [name]` target
different rollback operations.

Just as `beginTransaction()` and `savepoint()` are separate, perhaps
having a separate method for rolling back to a savepoint might
maintain consistency, for example `rollbackToSavepoint(string $name)`.

Regards.

Kentaro

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Are warnings guaranteed?

[petrov.boris.v.mail.ru via internals]

Hi. I have a question: Is there a formal rule in PHP standard library 
that any function which returns false as a mean to signify a failure 
does also issue a warning?


In many codebases warnings are converted to an exception by means of 
set_error_handler().


Example 1
--
set_error_handler(fn($_, $s) => throw new \RuntimeException($s));

if (false === mkdir('/doesn/t/exist/dir')) {
    throw new \RuntimeException("can't mkdir");
}
--

The above code confuses a reader with issues 1) isn't the only possible 
return value is now true? 2) if it throws on failure, then how can it 
return anything?


One may say the checking for false return value is redundant and the 
above version can be simplified based on premise that mkdir() emits 
warning in _all_ cases where it is about to return false.


Example 2
--
set_error_handler(fn($_, $s) => throw new \RuntimeException($s));

mkdir('/doesn/t/exist/dir');
--

But there is also a possibility that a built-in function fails, returns 
false but doesn't issue any warning, therefore the handler set with 
set_error_handler() doesn't get called and execution continues 
erroneously contrary to the programmer intend of it being halted.


Looking at mkdir() documentation I can't find the language supporting 
assumption made in Example 2.


The page lists two cases for which warnings are raised: "directory 
already exists" and "relevant permissions prevent creating the directory".
Does it mean that in case of "No such file or directory" the function 
would return false without raising a warning? It is possible as 
documentation never stated mkdir() would emit warning on _any_ failure, 
just return false.


One may add a unit-test against mkdir() to the one's project codebase 
proving that "Warning: mkdir(): No such file or directory" is raised 
too, despite not being listed in documentation.  So far we have three 
cases covered. But obviously this doesn't prove that a warning would be 
raised for all failures, thus doesn't allow us to deem Example 2 correct 
and replace Example 1 with it.


Is relying on warnings being converted to exceptions by error handler is 
equivalent to checking return value with regards to the set of error 
conditions covered? If this guarantee is already there, please point to 
me to the relevant documentation page.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Discussion] NotSerializable attribute

[Dennis Snell via internals]

> On Dec 9, 2023, at 4:55 PM, Robert Landers  wrote:
> 
> On Sat, Dec 9, 2023 at 4:32 PM Dennis Snell via internals
>  wrote:
>> 
>> Max, I love this idea.
>> 
>> Would it make sense to flip the design though and add `#[Serializable]` with 
>> a new `php.ini` setting?
>> 
>> I’m thinking that almost every class I use, if not every single class, 
>> should not be serialized.
>> If PHP had a flag to say “prevent all classes from serializing” then I could 
>> toggle that flag and
>> avoid changing every single one of the potentially thousands of classes in 
>> my codebase, and
>> I wouldn’t have to worry about ensuring that everyone creating a new class 
>> remembers to add
>> this attribute.
>> 
>> For existing sites with serializable classes we can leave the default of 
>> this new flag to the
>> permissive legacy behavior: every class is serializable. However, if you are 
>> willing and have
>> vetted your code you can flip that flag and now _unless_ you explicitly 
>> declare serializability
>> support, your classes don’t serialize or unserialize.
>> 
>> That could point to a future where _no_ class serializes _unless_ it 
>> implements `__sleep()`
>> and `__wakeup()` or `Serializable`, which seems quite reasonable in my mind 
>> as a tradeoff
>> between explicitness and surprise.
>> 
>> Warmly,
>> Dennis Snell
>> 
>>> On Dec 9, 2023, at 1:30 PM, Max Semenik  wrote:
>>> 
>>> Hi, I'd like to propose a new attribute, #[NotSerializable]. This
>>> functionality is already available for internal classes - userspace should
>>> benefit from it, too.
>>> 
>>> The RFC: https://wiki.php.net/rfc/not_serializable
>>> Proposed implementation: https://github.com/php/php-src/pull/12788
>>> 
>>> Please let me know what you think.
>>> 
>>> --
>>> Best regards,
>>> Max Semenik
>>> 
>>> --6c4879060c12de83--
>>> 
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>> 
> 
> Hi Dennis!
> 
> The biggest downside for the reverse of #[NotSerializable] is that it
> would break almost everything that uses serialize (e.g., WordPress
> caching, some Symfony/Doctrine things, SQS transports, etc.). Also,
> there is the question of whether this would apply to json_encode() or
> just serialize().

Thanks Robert,

My idea was that the flag, by default, would preserve the existing behavior.
A large codebase could decide to wait to disable serialization until every class
is appropriately marked.

Either way I guess a large refactor is resolved. With `#[Serializable]` the onus
is on making sure that features requiring serialization are marked as such. With
`#[NotSerializable]` the onus is on classes (which are not concerned with 
serialization)
to opt-out of something unrelated.

The RFC calls this out and it is awkward to implement `__wakeup()` with a 
throwing
exception. `#[Serializable]` takes that a step further in linking the two 
concepts only
where they are related.

> 
> PS. Please don't forget to bottom post on this list.

Thank you!

> 
> Robert Landers
> Software Engineer
> Utrecht NL

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][Discussion] NotSerializable attribute

[Dennis Snell via internals]

Max, I love this idea.

Would it make sense to flip the design though and add `#[Serializable]` with a 
new `php.ini` setting?

I’m thinking that almost every class I use, if not every single class, should 
not be serialized.
If PHP had a flag to say “prevent all classes from serializing” then I could 
toggle that flag and
avoid changing every single one of the potentially thousands of classes in my 
codebase, and
I wouldn’t have to worry about ensuring that everyone creating a new class 
remembers to add
this attribute.

For existing sites with serializable classes we can leave the default of this 
new flag to the
permissive legacy behavior: every class is serializable. However, if you are 
willing and have
vetted your code you can flip that flag and now _unless_ you explicitly declare 
serializability
support, your classes don’t serialize or unserialize.

That could point to a future where _no_ class serializes _unless_ it implements 
`__sleep()`
and `__wakeup()` or `Serializable`, which seems quite reasonable in my mind as 
a tradeoff
between explicitness and surprise.

Warmly,
Dennis Snell

> On Dec 9, 2023, at 1:30 PM, Max Semenik  wrote:
> 
> Hi, I'd like to propose a new attribute, #[NotSerializable]. This
> functionality is already available for internal classes - userspace should
> benefit from it, too.
> 
> The RFC: https://wiki.php.net/rfc/not_serializable
> Proposed implementation: https://github.com/php/php-src/pull/12788
> 
> Please let me know what you think.
> 
> -- 
> Best regards,
> Max Semenik
> 
> --00006c4879060c12de83--
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Inconsistency mbstring functions

[Stefan Schiller via internals]

On Mon, Dec 4, 2023 at 8:45 PM Alex  wrote:
>
> Stefan,
>
>>
>> My biggest concern is that this quirk can cause security issues in
>> user code. I came across this in the first place when discovering an
>> exploitable security vulnerability in an application. From my point of
>> view, this is not only about inconsistent behavior but also violates
>> the documentation for specific functions like mb_strstr. I agree that
>> a lot of mbstring operations should not be used on invalid strings,
>> and an exception seems to be an appropriate answer despite the huge BC
>> impact.
>
>
> 1) I'm sure the vulnerable application is proprietary, but can you at least 
> tell us which mbstring functions were directly involved in this 
> vulnerability, give an overview of the mechanism by which the exploit worked 
> (scrubbed of any specific details about the application), and let us know the 
> general nature of the resulting compromise? (i.e. denial-of-service, 
> information disclosure, allowing users to impersonate other users, etc)
>
> Real-life examples of actual security impact provide far more compelling 
> grounds for a BC break than hypothetical security impact.

The case I am referring to involves mb_strpos, which is used to
determine the index of a specific character, and mb_substr, which is
used to extract the substring until the first occurrence of this
character. For this specific case, this results in a Cross-Site
Scripting (XSS) vulnerability, which would allow an attacker to
perform actions on behalf of an authenticated user. The actual code is
more complex, but the following lines should be a suitable
representation of the issue:

$data = $_GET['data'];
$pos = mb_strpos($data, "<");
$out = $pos ? mb_substr($data, 0, $pos) : $data;
echo $out;

The developer's assumption here is that $out should never contain an
opening HTML tag, and it is thus safe to echo it back in the response.
Despite the fact that e.g. htmlspecialchars should be used to encode
the output, this assumption seems reasonable to me. However, due to
the inconsistent behavior, an attacker can break this assumption. If
$data, e.g., contains the sequence "\xf0AAA", str_pos will consider
the index of "<" to be 4. However, mb_substr assumes the full sequence
to have a length of 4 (1 x 4-byte Unicode character + 3 x 1-byte
Unicode characters). Accordingly, the full sequence, including the
"" tag, is reflected in the response.

>
> 2) Your point about documentation is appreciated. However, you should 
> consider the context. We are dealing with a 20+-year old library, with a 
> large installed base, which has (historically) always had inconsistent, 
> poorly defined semantics in edge cases, and which (historically) has always 
> had poor documentation. Don't forget Hyrum's Law, Stefan. Never forget 
> Hyrum's Law.
>
> In view of all this, we are usually much more likely to amend the mbstring 
> documentation to match behavior than to modify behavior to match 
> documentation. Now, that's not to say we can never modify mbstring behavior 
> to match documentation (I have done it myself several times), but there 
> should always be good reasons to prefer the new behavior (not just "because 
> that's what the documentation says").

I can fully understand your concerns, especially taking into account
the long-standing history of the library and Hyrum's Law. While the
above-mentioned example might even be arguable since two different
functions are involved, the behavior of, e.g., mb_strstr just feels
wrong to me:

$data = "\xf0start";
var_dump(mb_strstr($data, "start")); // string(2) "rt"

>
> 3) Modifying mbstring behavior to make the handling of invalid strings more 
> consistent is a smaller BC break than raising an exception. However, 
> completely refusing to operate on invalid strings (by raising an exception) 
> will be more effective in guarding against potential security vulnerabilities.

Considering BC, completely refusing to operate on invalid strings
seems like a huge break. From a
preventing-security-issues-in-user-code point of view, either of these
solutions seems appropriate.

>
> 4) Hamada-san is absolutely correct that all mbstring users should check 
> strings derived from user input using mb_check_encoding() before operating on 
> them. Unfortunately, "should" doesn't count for much. Most users will not do 
> what they "should".
>
> 5) Amending the documentation to call out these dangers more clearly would be 
> a positive step, though probably not enough.
>

In general, I like the idea of warning against pitfalls like this in
the documentation, although I estimate the effect, especially on
existing applications to be low.

Best Regards,
Stefan Schiller

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Inconsistency mbstring functions

[Stefan Schiller via internals]

On Sat, Dec 2, 2023 at 6:13 AM Alex  wrote:
>
> Dear Stefan, and Dear Gina,
>
> Thanks for the message. Yes, Stefan has rediscovered an interesting quirk of 
> the mbstring library. I have been aware of this for a long time, and other 
> mbstring developers have too. It dates back to the origin of the library; 
> actually, even before the origin of mbstring, since mbstring was based on 
> another library called libmbfl, and this behavior originates from libmbfl.
>
> Pull your chair up around the fire and let me tell you the tale of libmbfl. 
> Once upon a time, there was a text-processing library called libmbfl. libmbfl 
> was based on a collection of text-decoding routines (which converted bytes to 
> codepoints) and text-encoding routines (which converted codepoints to bytes). 
> Each such routine was structured as a stateful "filter". These filters could 
> be assembled into "chains", whereby the output values generated by one 
> routine would automatically be passed to the next. libmbfl could perform many 
> wonderful text-processing tasks by substituting a different final filter at 
> the end of the chain.
>
> But all was not well. Since libmbfl's filters processed text only one byte or 
> codepoint at a time, and each routine had to save its state before returning, 
> and restore its state upon entry, libmbfl was slow. Slow as a turtle, slow as 
> a snail, slow as whatever-slowly-moving-thing-you-can-think-of. Oh, what was 
> libmbfl to do? A clever plan was hatched: give libmbfl a 256-entry table 
> called a "mblen_table" for each supported text encoding with the property 
> that the byte length of a character can be determined from its first byte. 
> Then, text-processing tasks which were not dependent on the actual content of 
> a string, but only on the number of codepoints, could be performed without 
> ever invoking those wonderful, but painfully slow filters! libmbfl could skip 
> through a string while just examining the first byte of each character. (Of 
> course, this only worked for text encodings with an mblen_table.) For valid 
> strings, the new method worked identically to the previous one. For invalid 
> strings, there were significant differences in behavior, but libmbfl tried to 
> ignore these and bravely pressed on.
>
> The story ends with an ironic twist. Many years later, I became interested in 
> mbstring and reimplemented its internals, replacing the libmbfl code with 
> fresh new code which ran many times faster. The new code was so much faster 
> that in some cases, the mblen_table optimization actually became a 
> pessimization! In other cases, the mblen_table-based code is still faster, 
> but not by a large amount. But now mbstring was haunted by the spectre of 
> Hyrum's Law (https://www.hyrumslaw.com/). With a huge body of legacy code 
> relying on mbstring, almost any observable behavior change runs a significant 
> risk of breaking someone's code. And when this happens, they will not 
> hesitate to vent their rage on the hapless maintainers.
>
> Notwithstanding the rage of the users, about a year ago, I did remove the 
> mblen_table-based code in one place where benchmarks clearly showed it was 
> acting as a pessimization. I don't remember which mbstring function was 
> affected and would need to check the commit log to confirm.

Hi Alex,

Thank you very much for sharing this background context.

>
> Personally, I think the real issue here is not the inconsistency between 
> mbstring functions which are based on the mblen_tables and those which are 
> not. I think a lot of mbstring operations should not be used on invalid 
> strings at all, and that for such operations, mbstring would do well to throw 
> an exception if it receives invalid input. (Like mb_strpos; how do you define 
> the "position of a UTF-8 substring" when the parent string is not UTF-8 at 
> all?) But that would be a huge BC break.
>

My biggest concern is that this quirk can cause security issues in
user code. I came across this in the first place when discovering an
exploitable security vulnerability in an application. From my point of
view, this is not only about inconsistent behavior but also violates
the documentation for specific functions like mb_strstr. I agree that
a lot of mbstring operations should not be used on invalid strings,
and an exception seems to be an appropriate answer despite the huge BC
impact.

Best Regards,
Stefan Schiller

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [PDO] 2 phase commit

[Kentaro Takeda via internals]

Hi Eugene.

> 1. We have sent commit to the first database and it responded us with OK 
> (comitted)
> 2. Next we send commit to the second database, and it may be the case that in 
> that very moment we lose connection. Hence, if connection is lost before 
> final commit request, second database won't receive commit, and since It's 
> not aware of whether transaction should be committed or rolled back, data is 
> never made persistent.
>
> FWIK, this case is usually handled at the application level using async 
> commit in message consumers. Meaning commit operation will be retied again, 
> and again, and again until the connection is restored.
>
> Therefore, commit point is the point of no-return and network issues is the 
> problem we have to deal with.

This point highlights a critical and common challenge in deciding
whether to commit to a database.

Moreover, this consideration applies broadly to any side effects on
external systems, not solely to databases or two-phase commits.

Since the solution method differs depending on the system requirements
and specifications, I think developers should ensure safety through
their own implementation, and in other words, there is no need to
consider it as a capability of PHP itself.

Consider, for instance more generally, the following scenarios where
unintended loss of connectivity and processing interruptions are
critical.

* Send multiple HTTP requests with side-effects to external APIs at
the same time. If the connection is lost before the response is
returned.
* Processes that acquire locks, such as by creating a file in the
filesystem, rather than using locks from RDBMS, Redis, etc. If the
process is terminated abnormally by the OS while locked, it becomes
difficult to determine if the file's presence is due to an unfinished
process or an abnormal termination.

In both scenarios, consistency will be checked using another process
equivalent to the message consumers you mentioned, or some other
method.

In the case of a two-phase commit as well, I think that PHP itself MAY
do nothing (or SHOULD NOT do anything).

Regarts.

Kentaro Takeda

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Inconsistency mbstring functions

[Stefan Schiller via internals]

Hi,

I would like to raise attention to an inconsistency in how mbstring
functions handle invalid multibyte sequences. When, for example,
mb_strpos encounters a UTF-8 leading byte, it tries to parse the
following continuation bytes until the full byte sequence is read. If
an invalid byte is encountered, all previously read bytes are
considered one character, and the parsing is started over again at the
invalid byte. Let's consider the following example:

mb_strpos("\xf0\x9fABCD", "B"); // int(2)

The leading byte 0xf0 initiates a 4-byte UTF-8 sequence. The following
byte (0x9f) is a valid continuation byte. The next byte (0x41) is not
a valid continuation byte. Thus, 0xf0 and 0x9f are considered one
character, and 0x41 is regarded as another character. Accordingly, the
resulting index of "B" is 2.

On the other hand, mb_substr, for example, simply skips over
continuation bytes when encountering a leading byte. Let's consider
the following example, which uses mb_substr to cut the first two
characters from the string used in the previous example:

mb_substr("\xf0\x9fABCD", 2); // string(1) "D"

Again, the leading byte 0xf0 initiates a 4-byte UTF-8 sequence. This
time, mb_substr just skips over the next three bytes and considers all
4 bytes one character. Next, it continues to process at byte 0x43
("C"), which is regarded as another character. Thus, the resulting
string is "D".

This inconsistency in handling invalid multibyte sequences not only
exists between different functions but also affects single functions.
Let's consider the following example, which uses mb_strstr to
determine the first occurrence of the string "B" in the same string:

mb_strstr("\xf0\x9fABCD", "B"); // string(1) "D"

The principle is the same, just in a single function call.

This inconsistency may not only lead to an unexpected behavior but can
also have a security impact when the affected functions are used to
filter input.


Best Regards,
Stefan Schiller

[1]: https://www.php.net/manual/en/function.mb-strpos.php
[2]: https://www.php.net/manual/de/function.mb-substr.php
[3]: https://www.php.net/manual/de/function.mb-strstr.php

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

[Kentaro Takeda via internals]

> The migration path is to convert the legacy-encoding PHP files to UTF-8.

Please take a look at the following code.
This is a part of the code that I am actually maintaining in the
latest version of php.

```php
https://www.php.net/unsub.php

Re: [PHP-DEV] Set register_argc_argv to Off by default

[Thomas Chauchefoin via internals]

On Tue, Nov 7, 2023 at 11:46 AM Sebastian Bergmann  wrote:
> Am 07.11.2023 um 11:33 schrieb Thomas Chauchefoin via internals:
> > For instance, the official Docker image has it on [2].
>
> "Official" is relative here. That image is maintained by (the) Docker
> (community), it is not maintained by the PHP project.

Indeed, my bad. I've updated the GitHub issue to reflect that this
Docker image is not maintained by the PHP project.

On Tue, Nov 7, 2023 at 2:12 PM Kévin Dunglas  wrote:
> This change seems reasonable to me: safer, with little chance of breaking
> things, and easy to reverse for the end user by changing a single parameter.

On Tue, Nov 7, 2023 at 5:33 PM Matteo Beccati  wrote:
> Seriously though, I do agree with changing the default. I believe such
> check was added in a time when it was still common to use the cgi
> executable to run cli commands and the configuration was shared with
> mod_php.

On Tue, Nov 7, 2023 at 4:48 PM G. P. B.  wrote:
> This sounds sensible to me.

Thank you for your early feedback on this suggestion. Without rushing
things, I assume that the next step for me would be to draft an RFC to
formalize this change?

Best,
-Thomas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Set register_argc_argv to Off by default

[Thomas Chauchefoin via internals]

Hey,

I recently opened an issue on GitHub [1] to discuss setting
register_argc_argv to Off by default for all SAPIs but cli, embed, and
phpdbg. Ilija Tovilo suggested including this change in 8.4.0.

Even though most downstream distributions already turn it off, that's
not the case everywhere. For instance,  the official Docker image has
it on [2]. Outside of performance reasons, this also has a security
impact because it eases the exploitation of limited LFI bugs [3] and
CLI tools stored under the web root [4].

-Thomas

[1]: https://github.com/php/php-src/issues/12344
[2]: https://hub.docker.com/_/php
[3]: https://www.youtube.com/watch?v=yq2rq50IMSQ
[4]: https://github.com/advisories/GHSA-jm6m-4632-36hf

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

[Kentaro Takeda via internals]

Hi, Matteo

> Regarding this past issue with PostgreSQL, it can be solved by
> treating numbers larger than `int4` as `unknown` (as is the case now)
> rather than as `int8` (as in previous attempts).

I'm sorry, this was my mistake.


select 1::boolean ; -- returns `t`
select 1 = true ; -- `ERROR: operator does not exist: integer = boolean`


The conditions for casting and comparison were different.
`PDO_PARAM_INT` still needs to be passed as `unknown` to PostgreSQL.

Thank you!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

[Kentaro Takeda via internals]

Hi, Matteo,

> The last time I tried to fix the PDO_PARAM_INT behavior on pdo_pgsql I broke 
> Laravel and surely many other projects.
> https://github.com/php/php-src/pull/6801

Thank you for providing an important example.

Regarding this past issue with PostgreSQL, it can be solved by
treating numbers larger than `int4` as `unknown` (as is the case now)
rather than as `int8` (as in previous attempts).

This approach aligns with PostgreSQL's capability to cast `integer` to
`boolean` but not `smallint` or `bigint`. This consideration is
crucial for ensuring interoperability.


postgres=# select 1::integer::boolean ; -- returns `t`
postgres=# select 1::smallint::boolean ; -- `ERROR: cannot cast type
smallint to boolean`
postgres=# select 1::bigint::boolean ; -- `ERROR: cannot cast type
bigint to boolean`


It is certainly not realistic to unify behavior across all databases.
Also, as in the example above, there are certainly places where each
database requires individual support.

I think it would be good if a solution could be found that would allow
for more correct behavior without breaking the behavior of existing
applications.

Your insights and contributions are interesting and invaluable. They
are much appreciated.
Best regards

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

[Kentaro Takeda via internals]

Hi, internals.

> As shown in the following issue, the behavior of `PDO::PARAM_` is
> inconsistent and I would like to fix this.
> https://github.com/php/php-src/issues/12603

I consider the current behavior a bug.
And some of them contain behaviors that are very confusing to users.

> It may be an xkcd/1172 case, but these kinds of cases are very hard
> to spot from static analyzers, and are often only surfaced
> in production only if someone spent enough time to dig deep.

As previously discussed by Ayesh, assessing
the users' impact of a fix for this issue might be a little challenging,

but I think it's important to address it to prevent confusion.

Taking PostgreSQL as an example, let's consider the following PHP code:

```php
$pdo = new PDO('pgsql:');
$pdo->exec('create temp table t(boolean_column bool, text_column text)');

$stmt = $pdo->prepare('insert into t values (:v1, :v2)');
$stmt->bindValue(':v1', false, PDO::PARAM_BOOL);
$stmt->bindValue(':v2', false, PDO::PARAM_BOOL);
$stmt->execute();

$result = $pdo->query('select * from t');
var_export($result->fetchAll(PDO::FETCH_ASSOC));


The result should look like this:


array (
   0 =>
   array (
 'boolean_column' => false,
 'text_column' => 'f', // HERE!!!
   ),
)


Even if we insert `false`, it will change to `'f'` when we select it.

This is fundamentally a user mistake. However, the big problem in this case is
that the value `'f'` after the change is *truthy*. Who could have predicted
that even though you entered `false`, it ended up being `true` ?

I've seen a lot of pointless code to deal with problems
like this where types are not uniformly formatted.

As Saki says, we need to think carefully about whether
we can accurately treat this as `bool`.
However, regarding the above problem:

* Fix *truthy* / *falsy* such as `int(1)` / `int(0)` to a form that
can be correctly determined.
* Make this behavior consistent across as many drivers as possible.

Even this small fix would eliminate much of the confusion that is
currently occurring.
(Of course, it should ultimately be treated as `bool`.)

I look forward to a resolution that will be satisfactory to all.
Thank you for your attention.

2023年11月4日(土) 17:56 Saki Takamachi :
>
> Hi, Ayesh,
>
> I forgot to tell you one important thing.
>
> Binding of parameters is not actually done in the `bind`method, but in 
> the `execute()` method. Therefore, when preparing a new method, a slightly 
> larger mechanism is required to determine which method the parameter was set 
> through.
>
> Regards.
>
> Saki
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: New RFC : empty() function

[Brady Wetherington via internals]

> I have posted a new RFC at this link https://wiki.php.net/rfc/empty_function
> where I suggested some improvements to the standard built-in empty()
> function and provided a number of examples.

Is your "is_empty()" function equivalent to something like:

function is_empty($param = null)
{
return empty($param) && $param !== false && $param !== 0 && $param !== 0.0;
}

If so, that might actually be kinda nice? I was looking for something
like that the other day.

Regardless, I wouldn't do the BC-break; I'd be more inclined to (very
begrudgingly) leave empty() and warn against its use, and have
is_empty() as a new thing. Maybe for some future deprecation or
removal?

I also do like the idea that someone else mentioned here about being
able to possibly start to get away from @'ing variables with a
solution like this.

-B.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Levi Morrison via internals]

> > This is simply not true, 0 is not always the first key in a list,
> > especially after filtering it. Hence there is a need for this function
> > in the first place.
>
> Just to clarify this point: If 0 is not the first key, then it's not a list.
> After filtering a list, you get an array that may or may not be a list:
> https://3v4l.org/VegUr

I don't see how `array_is_list` is relevant to `array_first` and
`array_last`. PHP arrays are ordered:

$foo = [
"first" => 1,
"third" => 3,
];

It would be perfectly fine to use `array_first` or `array_last` with
`$foo`. I think probably you would use `array_key_first` and
`array_key_last` so you also get the key and not just the value, but I
don't see any need to reduce `array_first` and `array_last` to only be
logical or correct with arrays that uphold `array_is_list`.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Levi Morrison via internals]

> c) Two such functions were proposed and rejected during the
> array_key_first/last RFC
> (https://wiki.php.net/rfc/array_key_first_last)
>
> Yes, that was in 2018. At that time, functions like str_contains() or
> str_starts_with() wouldn't have even come into existence, just because
> there was an obscure way to do it without them. I believe we've moved
> on since then. Today we know how useful it is to use simple,
> easy-to-understand methods, both for programmers who write and read
> the code.

It's true that sentiment may have shifted in this time. However, a
common argument at that time still stands: `null` is not a good
sentintenal for failure because the value inside the array very well
could have been null. This is not true for the keys. For me
personally, I think I would still vote no. I'm not entirely sure about
that, but that's how I would lean right now.

As it stands, you'd have to write code along the lines of:

```php
$key = \array_key_first($array);
if ($key === null) {
// handle the failure
} else {
// success
$value = $array[$key];
}
```

Yes, it would be slightly nicer if we could do:

```php
$value = \array_first($array);
if ($value === null) {
// handle the failure
} else {
// success
}
```

But I fear in practice people will just omit the error checking.

One way around that is to throw an exception. I'm not sure how I feel
about that, but I'll think about it.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [PHP-DEF][RFC][VOTE] A new JIT implementation based on IR Framework

[Levi Morrison via internals]

On Thu, Oct 5, 2023 at 1:52 PM Dmitry Stogov  wrote:
>
> Hi internals,
>
> The vote on "A new JIT implementation based on IR Framework" RFC is started.
>
> https://wiki.php.net/rfc/jit-ir
>
> Thanks. Dmitry.

>From the RFC:

> The details of the IR framework are complex. This [presentation][1] explains 
> design ideas and makes overview of the most important implementaion details.

Was this presentation recorded and is it watchable somewhere? It looks
to have answers to many questions I had.

  [1]: 
https://www.researchgate.net/publication/374470404_IR_JIT_Framework_a_base_for_the_next_generation_JIT_for_PHP

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [Discussion] DOM HTML5 parsing and serialization support

[Dennis Snell via internals]

> Just chiming in here to say that while we don't offer a createFragment() in 
> this proposal, it's possible to parse fragments by passing the 
> LIBXML_HTML_NOIMPLIED option. Alternatively, in the future I plan to offer 
> innerHTML which you could use then in conjunction with 
> createDocumentFragment().


It’s not my understanding that this is right here, because fragment parsing 
implies more than having or not having the HTML and BODY elements implicitly.


> Sets HTML_PARSE_NOIMPLIED flag, which turns off the automatic adding of 
>implied html/body... elements.


The HTML5 spec defines fragment parsing as starting within a context node which 
exists within a broader document. For example, many people will parse a string 
of HTML that should form the contents of an LI element. They are grabbing that 
HTML from a database somewhere, from user input. If that HTML contains “” 
then our behavior diverges. In a fragment parser it would close out the list we 
started with but in full document parsing mode the end tag would be ignored, a 
parse error. If the goal is to ensure that user input doesn’t break out and 
change the page, then it’s important to use fragment parsing and grab the inner 
contents of that LI context node.


This can be valuable to have as a tool to guard against injection attacks or 
against accidentally breaking the page someone is building, because the 
fragment parser is aware of its environment. It becomes even more important 
when parsing within RCDATA or RAWTEXT sections. For example, if wanting to 
parse and analyze or manipulate a web page’s title then the parser should treat 
everything as plaintext until it reaches the end or encounters a closing TITLE 
tag. If trying to do this with `createFromString()` then it’s up to the caller 
to remember to prepend and then remove the environment, `createFromString( 
‘’ . $page_title . ‘’ )`. The fragment parser would be similar 
in practice, but more explicit and hard to misunderstand in these circumstances.


This is complicated stuff. I understand that the spec provides for a wide 
variety of use-cases and needs, and that it’s hard to pin down exactly what a 
spec-compliant parser is supposed to do in all situations (it depends), so I’m 
only wanting to share from the perspective of people doing a lot of small HTML 
manipulation. There’s not much code out there using the fragment parser, but I 
can’t help but think that part of the reason is because it’s not exposed where 
it ought to be.


Have a great weekend!
Dennis Snell
> 

Re: [PHP-DEV] Re: [RFC] [Discussion] DOM HTML5 parsing and serialization support

[Dennis Snell via internals]

> 
>> 
>> For both, `XMLDocument::fromEmpty` and `HTMLDocument::createEmpty` there is 
>> an argument available to define the encoding but none of the other 
>> `createFrom*` methods have this argument.
>> 
>> As far as I understand, in the these other cases the encoding gets detected 
>> from the content of the passed source but what happens is the source does 
>> not contain any information about the encoding?. E.g. you load an XML/HTML 
>> document over HTTP, the encoding is defined via HTTP header but the content 
>> itself doesn't contain it.
>> 
> 
> Right, we follow the HTML spec in this regard. Roughly speaking we determine 
> the charset in the following order of priorities.
> If one option fails, it will fall through to the next one.
> 1. The Content-Type HTTP header from which you loaded the document.
> 2. BOM sniffing in the content. I.e. UTF-8 with BOM and UTF-16 LE/BE prepend 
> the content with byte markers. This is used to detect encoding.
> 3. Meta tag in the content.
> 
> If it could not be determined at all, UTF-8 will be assumed as it's the 
> default in HTML.

It may sound meticulous, but I’ve tried to emphasize `createFragment()` in 
what’s being built in WordPress because almost everything being done on HTML 
within WordPress, and I think within many frameworks, is processing fragments 
(and usually short ones at that). Formerly I didn’t realize there was much of a 
difference, but text encoding is one of those differences. It’s my 
understanding that when parsing a fragment we have to assume an encoding, 
unless the fragment is starting at a spot in the document before that’s 
discovered, presumably only if we’ve constructed a Document with a 
still-unknown encoding.

So manually setting the encoding of a fragment constructor is not so much 
overriding as it is supplying, or at least, that’s one of two normative 
situations. If we create a fragment with a context node carrying an encoding 
already, then we need to ignore any meta tag that specifies otherwise; likewise 
if the context node doesn’t carry that encoding we do need to heed it.

I know there’s a huge difference in needs here between people writing scripts 
to scrape full HTML documents, but it’s not a small fraction of cases where 
people want to use DOMDocument without having the full HTML from start to 
finish. In the world I work in it’s usually either for parsing a small fragment 
to add some attributes or replace a wrapping tag, or for constructing HTML 
programmatically to avoid escaping issues and make nesting easy. In both of 
these cases the text encoding is implicit unless the function signature makes 
it explicit. At this stage in development, we only support some of the “in 
body” parsing and only support UTF-8, but I thought that it was important 
enough to add these as arguments to the creator function so that there’s an 
awareness that these values govern how the parse occurs.

Surely for `createFromString()` and `createEmpty()` we can make the assumption 
that no character encoding is set, but I also suspect that a possible majority 
of the times people use these functions they are likely calling them when 
`createFragment()` is more appropriate, that they aren’t supplying HTML 
documents with in-band text encoding information, and so there’s a chance that 
de-emphasizing the parameter may be technically more accurate and practically 
less helpful.

Love seeing all the continued work on this!
Thank you so much for your dedication to it.

Dennis Snell
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

[Levi Morrison via internals]

> Please find the following resources for your references:
>
> RFC Text: https://wiki.php.net/rfc/bcrypt_cost_2023
> Discussion Thread: https://externals.io/message/121004
> Feedback by a Hashcat team member on Fediverse:
> https://phpc.social/@tychotithonus@infosec.exchange/111025157601179075

I did a tiny bit of my own research, and could not find any
recommendations more specific than "10 or more" as the cost factor.
Typically, the advice is "use a more modern system like argon2id".

However, I did notice some sites mention that systems ought to check
for a maximum length of 72 bytes when using bcrypt:
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#input-limits

As far as I can tell, PHP does not do this check. I am not sure if the
implementation(s) used suffer(s) from the limitation that is the
source of this recommendation. Perhaps someone has time to investigate
this? Anyway, it's "future work."

I have voted for 11, but will not be hurt in any way if 12 wins.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] DOM HTML5 parsing and serialization support

[Dennis Snell via internals]

> On Sep 19, 2023, at 12:30 AM, Tim Düsterhus  wrote:
> 
> From the perspective of the user of the API, I like the symmetry between all 
> the named constructors:
> 
> Whenever I want to create a new document, I use one of the fromXyz() methods. 
> And when I use those, I get exactly what it says on the tin.
> 
> Making the regular constructor available for use would effectively make 
> whatever that constructor does a special case / the default case.


Just wanted to voice my support for this too. In the WordPress HTML API I 
regret exposing a public constructor on the underlying lexer because that 
prevented me from hiding the constructor on the HTML parsing class, leading to 
an awkward convention to try and beg people not to use it.

Why? the constructor performs various state initialization important for HTML, 
not only for the encoding, but in our case I felt it was important enough that 
we provide both a full-document interface and also the HTML fragment parser, 
since almost all of the actual HTML parsing we do is one fragments. This 
_could_ be something to consider here in the HTMLDocument API as well.

The use of the constructor directly opens up opportunities to bypass that state 
initialization which could lead to incorrect parse results, not only for 
encoding issues, but also in getting way off track in parsing. E.g. if we’re 
parsing the inner contents of a TEMPLATE element then a closing BODY tag should 
be ignored whereas in other parsing modes it closes the BODY element.

> For the HtmlDocument I find it less obvious that creating an empty document 
> would be the default case compared to loading an existing document from a 
> file.


To hit the point home, “creating an empty document” seems a little unclear in 
terms of HTML as well. Are we creating am empty DOM class instance without any 
actual DOM? Are we creating a  DOM with no nodes? If we proceed 
by feeding it an HTML string and parsing then we can resolve the ambiguity, but 
if we start inserting DOM nodes directly that leaves us in an undefined 
starting point.

Presumably we don’t need this empty method because we could `loadString( ‘’ )`, 
but that leaves open the ambiguities of what kind of empty we’re making. In my 
experience with HTML, any kind of “empty” is going to need a definition of its 
own, and a static creator method is the right place to define and parameterize 
that, as in the updated RFC, though maybe with an additional clarification of 
what “empty” means and what implications it carries for ongoing manipulation.

—

Having static creator methods with docblocks and named arguments to me is a 
great way to not only guide people to use these classes safely, but also to 
teach some of the nuances that have historically been overlooked in PHP’s HTML 
handling, e.g. `html_entity_decode()` is unaware of of the ambiguous ampersand 
and offers no way to correctly parse certain kinds of invalid named character 
references.

Kindly,
Dennis Snell
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Björn Larsson via internals]

Den 2023-09-11 kl. 11:28, skrev Dmitry Stogov:

Hi internals,

I'm glad to present a new JIT engine that is going to be used in the next
major PHP version. Now it's a real optimizing compiler with Intermediate
Representation similar to Java HotSpot server compiler.

It makes a base for future improvements and eliminates many low-level
details of the existing PHP JIT. Instead of supporting assembler code for
different CPUs, now PHP generates a single IR and passes it to a
PHP-independent JIT engine.

The old JIT implementation is going to be kept for a while.

Everybody are welcome to take a look over tne code
https://github.com/php/php-src/pull/12079

Thanks. Dmitry.


Great work Dmitry! Looking forward to test it in next major PHP version.

Are there any performance figures available for this new JIT engine?

Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] [Discussion] DOM HTML5 parsing and serialization support

[Dennis Snell via internals]

ems with spec compliance.
> I only recently got into maintaining ext/dom. So there's still a lot of work 
> to do.
> I had already started with adding more DOM APIs in the 8.3 release cycle and 
> plan to continue that effort in 8.4.
> Another major project I want to do for 8.4, besides HTML5 support, is fixing 
> the spec compliance issues in an opt-in manner. This would help with security 
> & sanitization problems (HTML5 should help with the encoding).
> 
>> 
>> Warmly,
>> Dennis Snell
> 
> Kind regards
> Niels
> 
>> 
>>> On Sep 2, 2023, at 12:41 PM, Niels Dossche >> <mailto:dossche.ni...@gmail.com>> wrote:
>>> 
>>> I'm opening the discussion for my RFC "DOM HTML5 parsing and serialization 
>>> support".
>>> https://wiki.php.net/rfc/domdocument_html5_parser 
>>> <https://wiki.php.net/rfc/domdocument_html5_parser>
>>> 
>>> Kind regards
>>> Niels
> 

Impressive proposal. It will be nice to have. Did you consider any tricks for 
text encoding, such as converting non-utf8 documents into utf8 first before 
parsing? Was wondering if we did that if we could lean on `iconv` and save the 
extra data in the library, if that’s important enough.

Cheers,
Dennis Snell

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] [Discussion] DOM HTML5 parsing and serialization support

[Dennis Snell via internals]

Thanks for the proposal Niels,

I’ve dealt with my own grief working through issues in DOMDocument and wanting 
it to work but finding it inadequate.

> HTML5

This would be a great starting point; I would love it if we took the 
opportunity to fix named character reference decoding, as PHP has (to my 
knowledge) never respected (at least in HTML5) that they decode differently 
inside attributes as they do inside markup, considering rules such as the 
ambiguous ampersand and decode errors.

It’s also been frustrating that DOMDocument parses tags in RCDATA sections 
where they don’t exist, such as in TITLE or TEXTAREA elements, escapes certain 
types of invalid comments so that they appear rendered in the saved document, 
and misses basic semantic rules (e.g. creating a BUTTON element as a child of a 
BUTTON element instead of closing out the already-open BUTTON).

I’d like to share some what a few of us have been working on inside WordPress, 
which is to build a conformant streaming HTML5 parser:
 - https://developer.wordpress.org/reference/classes/wp_html_tag_processor/
 - https://make.wordpress.org/core/2023/08/19/progress-report-html-api/

It’s just food for thought right now because adding HTML5 support to 
DOMDocument would benefit everyone, but we decided we had common need in PHP to 
work with HTML not in a DOM, but in a streaming fashion, one with very little 
runtime overhead. My long-term plan has been to get a good grasp for the 
interface needs and thoroughly test it within the WordPress community and then 
propose its inclusion into PHP. It’s been incredibly handy so far, and on my 
laptop runs at around 20 MB/s, which is not great, but good enough for many 
needs. My naive C port runs on the same laptop at around 80 MB/s and I believe 
that we can likely triple or quadruple that speed again if any of us working on 
it knew how to take advantage of SIMD instrinsics.

It tries to accomplish a few goals:
 - be fast enough
 - interpret HTML as an HTML5-compliant browser will
 - find specific locations within an HTML document and then read or modify them
 - pass through any invalid HTML it encounters for the browser to resolve/fix 
unless modifying the part of the document containing those invalid constructions

I only bring up this different interface because once we started digging deep 
into DOMDocument we found that the problems with it were far from superficial; 
that there is a host of problems and a mismatched interface to our common 
needs. It has surprised me that PHP, the language of the web, has had such 
trouble handling HTML, the language of the web, and we wanted to completely 
resolve this issue once and for all within WordPress so we can clean up 
decades’ old problems with encoding, decoding, security, and sanitization.

Warmly,
Dennis Snell

> On Sep 2, 2023, at 12:41 PM, Niels Dossche  > wrote:
> 
> I'm opening the discussion for my RFC "DOM HTML5 parsing and serialization 
> support".
> https://wiki.php.net/rfc/domdocument_html5_parser
> 
> Kind regards
> Niels

Re: [PHP-DEV] [VOTE] Support optional suffix parameter in tempnam

[Levi Morrison via internals]

On Sun, Aug 27, 2023 at 4:20 AM Tim Düsterhus  wrote:
>
> Hi Athos
>
> On 8/27/23 04:02, Athos Ribeiro wrote:
> > I am moving this RFC [1] to the voting phase.  Voting will be open for the
> > next 2 weeks, until September 10th, as per https://wiki.php.net/rfc.
> >
> > [1] https://wiki.php.net/rfc/tempnam-suffix-v2
> >
>
> I find this a useful feature in general, but I believe it not working on
> Windows completely nullifies the "could even provide more context for
> software processing such files" argument in favor of this feature. It
> will be unexpected for users if their code completely fails to work on
> Windows, because the suffix is ignored.
>
> For that reason I voted "no".
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php


I have voted no for a similar reason. It would be nice if there were
os-specific packages in core that handled these kinds of things,
because the functionality is definitely useful. But if you call an API
like `FileSystem\Os\Unix\tempnam` then at least the platform specific
behavior is obvious and understood.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: ICU - NumberFormatter::ROUNDING_MODE default ROUND_HALFEVEN

[Hans Krentel via internals]

On Thursday 03 August 2023 21:07:57 (+02:00), Ben Ramsey wrote:

>
> 
> The default rounding mode in ICU for the number formatter appears to be 
> "half even," and that's probably why it's the default in PHP.
> 
> See:
> 
> - 
> 
https://unicode-org.github.io/icu/userguide/format_parse/numbers/rounding-modes#half-even




> - 
> 
https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1number_1_1NumberFormatterSettings.html#aceb7d34843e0d44e138fb3f43c98db32




> The MDN documentation you linked to describes the JavaScript 
> implementation of ECMA-402, which differs from ICU in a number of ways. 
> One of which is in the default rounding mode for `Intl.NumberFormat`, 
> which is not the same as ICU's `NumberFormatter` (even though most 
> ECMA-402 implementations use icu4c internally).
> 
> Here's where ECMA-402 defines `halfExpand` as the default for 
> `roundingMode` (see step 10 under section 15.1.3):
> 
> https://tc39.es/ecma402/#sec-setnfdigitoptions
> 
> Since PHP's intl extension follows icu4c and not ECMA-402, I think it 
> makes sense for it to continue to use the same default values as icu4c.



Thank you for this differentiation, my reference to MDN I found
interesting as they've chosen the same approach as PHP with
number_format(), obviously they also choose the name of the function
because of that^^.

Jokes aside, your reference to ICU itself and PHPs connection to it
is most likely the true explanation why that is the default rounding
mode in NumberFormatter.

And honestly, from a core perspective, it would likely be surprising
if it would be otherwise then (the change asked about).

I'm not the person to draw this line, but in hindsight of output
formatting - obviously the totally other side - the current default is
surprising, too.

But it is certainly the safer path to not change it.


For now, I've already learned a lot more and should take some time to
look into this. E.g. understanding why this is the default in ICU,
perhaps there is some more valuable information.

Thanks & Best,

-- hakre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] ICU - NumberFormatter::ROUNDING_MODE default ROUND_HALFEVEN

[Hans Krentel via internals]

On Thursday 03 August 2023 21:07:35 (+02:00), Tim Düsterhus wrote:

> Hi
> 
> On 8/3/23 20:55, Hans Krentel via internals wrote:
> > Feedback from actual ICU caretakers would be good though, because me
> > is entirely from a users perspective, also I know how to change
> > attributes to non default values, this is not a programming question
> > I have.
> > 
> Would the updated default also affect `->formatCurrency()`?

Yes, it exactly affects that, this was the case Q:


$formatter = new NumberFormatter('en', NumberFormatter::CURRENCY);

$formatter->setAttribute(
NumberFormatter::ROUNDING_MODE,
NumberFormatter::ROUND_HALFUP
);


echo $formatter->formatCurrency(31.005, 'USD'), "\n";
# Output: $31.01


> When formatting currencies, HALFEVEN is preferable to reduce the impact of 
> rounding errors.


Yes, for rounding, no for formatting. If I'm not mistaken:

When rounding, HALFEVEN is preferred for the reason that it's done for
multiple values being calculated further on, as it levitates rounding
errors over the common number distributions in a line.

When formatting, HALFUP is preferred for the reason that floating point
numbers are with errors of the unit in the last place. Here it is
demanded for as the formatting is for final display, not an ongoing
calculation.

As far as I could receive it over the years, users are happy with the
results PHPs' number_format() yields to them.

> 
> Best regards
> Tim Düsterhus
> 


Thank you for highlighting this feature of HALFEVEN Tim, it's also
called _banker's rounding_ and is the default offering if I got this
right from IEEE binary float for rounding.

Which I assume could be one explanation for the current default.

Best,

-- hakre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] ICU - NumberFormatter::ROUNDING_MODE default ROUND_HALFEVEN

[Hans Krentel via internals]

This is a proposal to consider to discuss/change the default value of

NumberFormatter::ROUNDING_MODE

from current

NumberFormatter::ROUND_HALFEVEN

to

NumberFormatter::ROUND_HALFUP

.

I got the attention of this from an unrelated user in an online forum
(SO) and also checked with MDN which has it as default as well. [1]

If I'm not mistaken, ROUND_HALFUP is the rounding with number_format()
and the default rounding mode with round().

Feedback from actual ICU caretakers would be good though, because me
is entirely from a users perspective, also I know how to change
attributes to non default values, this is not a programming question
I have.

I hope you don't mind the attention to detail.

Best

-- hakre

[1]: 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat/NumberFormat#roundingmode


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Interface Default Methods

[Levi Morrison via internals]

On Sun, Jul 2, 2023 at 6:11 PM Levi Morrison  wrote:
>
> Chatter on the [Interface Default Methods RFC][1] has been quiet for
> the past 6 days, and the feature freeze deadline is fast approaching
> for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
> as usual.
>
> Thanks to everyone who discussed weaknesses in the RFC during the
> discussion phase.
>
>   [1]: https://wiki.php.net/rfc/interface-default-methods

The voting has ended. The final vote count is 15 yes to 17 no, so this
RFC is not accepted. Thanks to those who participated in the
discussion and the voting.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] freopen() function

[Mikhail Galanin via internals]

Hi there,

I was checking our codebase and realised that we still use the
function proposed by Antony a long time ago [1]. I run through the
comments and feel like I can address the issues discussed back then.

My question is what would be the best way to move forward? Shall I
reopen the PR, create new or would it be better to start with a RFC?


Links:
[1] https://github.com/php/php-src/pull/950
[2] https://linux.die.net/man/3/freopen

Thanks

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Interface Default Methods

[Brent Roose via internals]

I want to pitch in, agreeing with Larry's message here. 

- There are multiple real life use cases where the combo trait/interface could 
be replaced by interface default methods
- Several modern language apply the technique in one form or another, so it's 
already proven to be valuable
- There are a multitude of userland devs who'd benefit from this feature
- The only argument I've heard against this RFC is "it goes against my 
definition of what an interface should be". I was also thought that same 
definition, and I also had to unlearn it. Just like I had to unlearn the "only 
one return per method rule" we were taught in college

Brent

> On 12 Jul 2023, at 20:17, Larry Garfield  wrote:
> 
> On Wed, Jul 12, 2023, at 4:00 AM, G. P. B. wrote:
>> On Mon, 3 Jul 2023 at 01:11, Levi Morrison  wrote:
>> 
>>> Chatter on the [Interface Default Methods RFC][1] has been quiet for
>>> the past 6 days, and the feature freeze deadline is fast approaching
>>> for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
>>> as usual.
>>> 
>>> Thanks to everyone who discussed weaknesses in the RFC during the
>>> discussion phase.
>>> 
>>>  [1]: https://wiki.php.net/rfc/interface-default-methods
>>> 
>> 
>> Although I like the idea, I think the main reason for the pushback is how
>> close this is being voted on before feature freeze when the RFC +
>> implementation was updated very recently before.
>> And personally I think, considering this, I would also delay implementing
>> this.
>> We have at least 2 other major RFCs that are being pushed back (Property
>> Hooks and Function autoloading) due to time constraints.
>> 
>> Maybe it's time for a more meta discussion about the absurdly long release
>> process PHP has of releasing many intermediate versions that seem to get no
>> testing from userland.
>> 
>> For everyone against this feature, I would urge you to understand the
>> distinction between "type classes" and Java-like "interfaces" (which is
>> effectively what PHP interfaces are).
>> A good article is the following one:
>> https://diogocastro.com/blog/2018/06/17/typeclasses-in-perspective/
>> 
>> I also find it baffling the lack of understanding around this feature.
>> Generic programming exists, and it operates on a level where a method can
>> have a "concrete" default representation and still represent the genericity
>> to its fullest.
>> Examples have already been given, such as the Comparable, Equatable, or
>> Iterator type classes.
>> Considering, Haskell, Rust, Scala, and modern PL theory sees no issue with
>> that, I struggle to understand the resistance here.
> 
> If I could play armchair shrink for a moment, I suspect a lot of people come 
> from a background where "interface is just the behavior definition, not 
> implementation" was drilled into them.  Which... is the case in older Java 
> when most of us went through school using older Java.  So it's natural to 
> think that is just a rule of how languages work, and so default methods in 
> interfaces is just some weird nonsense from people who don't understand 
> language theory because you didn't learn it in school.
> 
> At least, I know that description applies to me, so I'm assuming it applies 
> to at least some other folks around here. :-)
> 
> Realizing "oh, wait, I was wrong about the theory of how things work" is 
> uncomfortable, and hard for a lot of people.  I was initially luke-warm on it 
> for that reason. But seeing how many languages have adopted some form of 
> default methods and lived to tell the tale is convincing for me that it 
> actually is a viable "build up a class from separate pieces without having to 
> manually write 50 proxy methods" solution.  There may be smaller issues with 
> it that need to be ironed out (enforcing methods being defined, it working 
> better with interface properties, etc.), but the core idea seems to be sound.
> 
> It's taken me a while to get used to going through that "oh wait, I was 
> wrong" process, so at this point it's not an ego-hit.  But that's not a 
> process everyone has gone through.
> 
> In short, I suspect at least much of the pushback is "that is weird and not 
> normal, according to the normal I first learned, so it must be a bad idea," 
> and people just stop there.
> 
> (If you voted no and the above description doesn't apply to you, please do 
> explain what your alternate reasoning is, because RFC authors desperately 
> need more feedback than we get right now.)
> 
> --Larry Garfield
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Interface Default Methods

[Levi Morrison via internals]

On Mon, Jul 3, 2023 at 2:54 AM Tim Düsterhus  wrote:
>
> Hi
>
> On 7/3/23 02:11, Levi Morrison wrote:
> > Chatter on the [Interface Default Methods RFC][1] has been quiet for
> > the past 6 days, and the feature freeze deadline is fast approaching
> > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
> > as usual.
>
> I'm not really sold on the proposal in the first place, but I find it
> incredibly problematic that there were non-trivial changes to the RFC
> text just 4 minutes before voting started and having the justification
> "it will be easier to change if bad".
>
> Combined with the phrasing of the email I'm replying to, it looks like
> this proposal is attempted to be forced into PHP 8.3 for some reason,
> without fully thinking it through / without allowing an in-depth
> discussion. This is probably going to bite in the longer term.
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

I suppose different people will think different things about what
'trivial' means, but the main changes were announced 6 days earlier on
the mailing list, and there was no discussion about it all. I consider
that to be fine. I also do not consider that to be hurried.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate remains of string evaluated code assertions

[Levi Morrison via internals]

On Wed, Jun 28, 2023 at 10:09 AM G. P. B.  wrote:
>
> Hello internals,
>
> I'm opening the vote for the
> Deprecate remains of string evaluated code assertions RFC:
> https://wiki.php.net/rfc/assert-string-eval-cleanup
>
> It will last for two weeks and end on Wednesday the 12th of July
>
> Best regards,
>
> George P. Banyard

I voted in favor, which shouldn't be surprising given I'm the one who
wrote the PR to default assert.exception to 1 for PHP 8. Thank you for
continuing to clean up this mess.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Interface Default Methods

[Levi Morrison via internals]

On Tue, Jun 20, 2023 at 9:46 PM Levi Morrison  wrote:
>
> On Tue, Jun 20, 2023 at 6:29 AM David Gebler  wrote:
> >
> > On Tue, 20 Jun 2023, 04:10 Levi Morrison,  wrote:
> >
> > > > I like the idea of this RFC - in fact it's one which has been near top 
> > > > of
> > > > my wishlist for PHP language features for a long time - but I think this
> > > is
> > > > an issue with the proposed implementation which at the very least
> > > warrants
> > > > highlighting and discussion.
> > >
> > > I understand your concern but personally believe it's overblown. This
> > > problem already exists with abstract classes, but doesn't seem to be
> > > that much of an issue in practice. I hope static analysis can fill the
> > > gap here, but don't think these checks are necessary to ship this
> > > feature.
> > >
> >
> >
> > Yeah I suppose I'm just saying "Interface default methods" can be
> > interpreted a few different ways and there's key differences between
> > Java-style, versus syntax sugar for mixing an interface and a trait in to
> > one unit, versus a user can effectively extend multiple abstract classes
> > but with interface keyword.
>
> I will update the RFC soon. In my head it was so obvious that it would
> be similar to regular inheritance and less like traits, to the extent
> I didn't even realize I'd need to specify it. This is why discussion
> periods can be valuable; the RFC doesn't always say what's in the RFC
> author's head :)


I have significantly updated the RFC. There's one more topic that
needs to go in there, tentatively called 'default cancelling':

```php
interface Interface1 { function m1() { /* ... */ } }
interface Interface2 extends Interface1 {
function m1(); // may or may not change signature
}
```

For various reasons which I'll put in the RFC, this will "cancel" the
default, meaning any class which implements Interface2 instead of
Interface1 will not receive that default.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] PHP 8.3 deprecations

[Björn Larsson via internals]

Den 2023-06-22 kl. 14:52, skrev Nicolas Grekas:


As previously announced on the list, we have just started the vote about
the annual PHP deprecation RFC.

Link to the RFC: https://wiki.php.net/rfc/deprecations_php_8_3
Link to the discussion thread: https://externals.io/message/120422

The vote is open until 2023-07-06 12:00:00 UTC.



Thanks Mate for moving all this forward.

I wish we could have voted to keep rand() and getrandmax() and just change
them to use the CSPRNG, like we do for  array_rand() & co. but I guess this
should have been proposed earlier. Might be worth a small follow up RFC to
not disrupt the current one.

Cheers,
Nicolas


Sounds like a good idea to me, keeping the functions and making them
better. Hope it will fly!

Not sure if this is a relevant comparison, but we have code that we now
need to change due to deprecation of utf8_decode and utf8_encode. It is
code that has been working flawlessly for 9 years, so it's only work and
no benefit. Given that deprecations are piling up for 8.x track I think
one should be a bit cautious when approaching the next major version.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [PHP8.3] Feature freeze in 4 weeks

[Eric Mann via internals]

Good morning, all!

This is a friendly reminder from your RMs that the PHP 8.3 feature 
freeze is in ~4 weeks on July 18th [1]. Alpha1 is already out and Alpha2 
is scheduled this Thursday.


All new features and RFCs need to be discussed with voting polls closed 
on or before July 18th for inclusion in PHP 8.3.


Thanks everyone for the stellar work!

[1] https://wiki.php.net/todo/php83

--
PHP Cookbook 
*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA 
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com 
ttmm.io 
Twitter icon  LinkedIn icon 

Re: [PHP-DEV] [RFC] Interface Default Methods

[Levi Morrison via internals]

On Sat, Jun 17, 2023 at 4:10 PM David Gebler  wrote:
>
> On Thu, Jun 15, 2023 at 4:48 AM Levi Morrison via internals 
>  wrote:
>>
>>
>> I am moving my RFC for interface default methods to discussion:
>> https://wiki.php.net/rfc/interface-default-methods.
>>
>
> Can I ask, the RFC doesn't say - does your implementation ensure default 
> implementations can only call other methods which exist on the interface in 
> the same manner as Java? i.e. the following would give some sort of error?
>
> interface A {
> public function foo(): void {
> $this->bar();
> }
> }
>
> class B implements A {
> public function bar(): void {
> ...
> }
> }
>
> But the following would be okay?
>
> interface A {
> public function foo(): void {
> $this->bar();
> }
>
> public function bar(): void;
> }
>

No, there's no attempt to ensure the method body adheres to calling
the public interface. Due to PHP's possible dynamic behaviors, I don't
think it's reasonable to attempt to enforce it at compile-time. I'm
not sure it's worth the effort trying to enforce it at runtime either,
but it would be nice to see lints from static analysis tools which
detect this issue.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Interface Default Methods

[Levi Morrison via internals]

On Fri, Jun 16, 2023 at 11:51 AM Deleu  wrote:
>
>
> On Thu, Jun 15, 2023 at 12:48 AM Levi Morrison via internals 
>  wrote:
>>
>> Hello, PHP Internals,
>>
>> I am moving my RFC for interface default methods to discussion:
>> https://wiki.php.net/rfc/interface-default-methods.
>>
>> This can be a useful tool for a few reasons:
>>  1. It can make implementing an interface easier when certain methods
>> can be implemented by other methods in the interface. For example, if
>> `Countable` had an `isEmpty(): bool` method, it could be implemented
>> by doing `$this->count() > 0`. Of course, if an implementation can be
>> more efficient, they are still free to implement it how they want.
>>  2. It can mitigate BC breaks in some cases. It's somewhat common for
>> authors to want to expand new methods onto existing interfaces over
>> time. Although this would still be a BC break, it moves it from a
>> massive change (every single implementor must add something, even if
>> it's a stub, or it will fail to compile) to a naming collision issue
>> only (only classes which already had a method of the same name will
>> fail to compile).
>>
>> There is prior art for this feature in both Java and C#. There may be
>> other languages, but I was aware of at least these.
>>
>> Note that the RFC links to a partial implementation. If there are two
>> or more interfaces with default methods of the same shape (name, args,
>> etc) and a class implements both interfaces and doesn't provide a
>> concrete implementation, which default implementation should be
>> chosen? There is a proposal for resolving this in some cases which is
>> modelled after Java's implementation, but it isn't implemented.
>>
>> Thank you for your time. I look forward to productive feedback.
>>
>> Levi Morrison
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>
> A question just occurred to me. Building up on the example of the RFC, is the 
> following snippet valid and would it behave as expected?
>
> ```
> interface Interface1 {
> function method1() { echo __METHOD__ . "\n"; }
> }
>
> interface Interface2 {
> function method1() { echo __METHOD__ . "\n"; }
> }
>
> class Class1 implements Interface1, Interface2 {
> function method1() {
> $result = Interface1::method1();
>
>     Interface2::method1();
>
> return $result;
> }
> }
>
> $result = (new Class1())->method1();
> ```
>
>
> --
> Marco Deleu

I'm not sure why you are saving `null` from `Interface1::method1()`'s
implicit return and then returning it from inside `Class1::method1`,
but yes, this is valid.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Interface Default Methods

[Levi Morrison via internals]

On Thu, Jun 15, 2023 at 3:37 PM Ilija Tovilo  wrote:
> > I am moving my RFC for interface default methods to discussion:
> > https://wiki.php.net/rfc/interface-default-methods.
>
> The RFC doesn't mention default implementations for static methods.
> I'm not sure there's a use case but it might make sense to explicitly
> mention whether they are supported.

Interesting point. I sometimes forget that `static` is allowed in
interfaces. When I rebase the branch, I'll check it out. I assume it
works at a technical level without issues. If that's true, then absent
further evidence, I would say to allow it.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Interface Default Methods

[Levi Morrison via internals]

On Thu, Jun 15, 2023 at 9:16 AM Tim Düsterhus  wrote:
>
> Hi
>
> On 6/15/23 17:08, Deleu wrote:
> > The feature may introduce a new way for *Users of PHP* to break BC with
> > *Other Users of PHP*. The language change itself has no impact on PHP code
> > written prior to the feature. The additional note about how users may break
> > BC by using the feature would be a description of the feature itself, thus
> > might be best declared as part of the Proposal instead.
> >
>
> There's also the possible impact with regard to static analysis tools,
> IDEs and formatters that do not expect a method body to exist within
> interfaces and thus might erroneously report such an interface as
> invalid. This might be considered an impact on code written prior to the
> feature existing.
>
> Best regards
> Tim Düsterhus

I have added a brief section in RFC impact that code analysis tools
will need to be updated. This is implicitly true for many language
features, but I see no harm in calling it out in the RFC, so I have
done so. Thank you for the feedback.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Interface Default Methods

[Levi Morrison via internals]

> I still believe this information should be added to the RFC as the risk
> of adding new methods to an interface which collide with existing
> methods in implementations of that interface is very real, though I
> agree with Deleu that this BC impact is not so much of the RFC, but of
> what can happen once the RFC would be accepted.

Juliette, it's in the RFC under the second bullet point here:
https://wiki.php.net/rfc/interface-default-methods#backward_incompatible_changes.
Is there something specific you'd like added there?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [RFC] Interface Default Methods

[Levi Morrison via internals]

Hello, PHP Internals,

I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.

This can be a useful tool for a few reasons:
 1. It can make implementing an interface easier when certain methods
can be implemented by other methods in the interface. For example, if
`Countable` had an `isEmpty(): bool` method, it could be implemented
by doing `$this->count() > 0`. Of course, if an implementation can be
more efficient, they are still free to implement it how they want.
 2. It can mitigate BC breaks in some cases. It's somewhat common for
authors to want to expand new methods onto existing interfaces over
time. Although this would still be a BC break, it moves it from a
massive change (every single implementor must add something, even if
it's a stub, or it will fail to compile) to a naming collision issue
only (only classes which already had a method of the same name will
fail to compile).

There is prior art for this feature in both Java and C#. There may be
other languages, but I was aware of at least these.

Note that the RFC links to a partial implementation. If there are two
or more interfaces with default methods of the same shape (name, args,
etc) and a class implements both interfaces and doesn't provide a
concrete implementation, which default implementation should be
chosen? There is a proposal for resolving this in some cases which is
modelled after Java's implementation, but it isn't implemented.

Thank you for your time. I look forward to productive feedback.

Levi Morrison

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Levi Morrison via internals]

On Wed, Jun 14, 2023 at 4:06 AM Derick Rethans  wrote:
>
> On Tue, 13 Jun 2023, Nicolas Grekas wrote:
>
> > > I'm going to nitpick on the newly suggested names and argument order for
> > > the
> > > DatePeriod factory methods — althoughI do agree that they need to get
> > > created:
> > >
> > > createFromInterval(DateTimeInterface $start, DateInterval $interval,
> > > DateTimeInterface $end, int $options = 0)
> > > → createWithRange(DateTimeInterface $begin, DateTimeInterface $end,
> > > DateTimeInterface $int, int $options = 0)
> > >
> > > createFromRecurrences(DateTimeInterface $start, DateInterval $interval,
> > > int $recurrences, int $options = 0)
> > > → createWithRecurrences(DateInterval $begin, int $recurrences,
> > > DateInterval $interval, int $options = 0)
> > >
> > > We also should fix the argument names. Either $start/$finish, or
> > > $begin/$end. I
> > > prefer the latter.
> > >
> > > createFromIso8601(string $specification, int $options = 0)
> > > -> createFromISO8601String
> > >
> > > I am open to bike shedding about this :-)
> > >
> >
> > On my side, I'd very much prefer keeping the constructor of DatePeriod and
> > thus making it non-overloaded with this signature:
> >
> > public function __construct(DateTimeInterface $start, DateInterval
> > $interval, DateTimeInterface|int $end, int $options = 0) {}
>
> That still has an overloaded third argument — DateTimeInterface|int.

This specific case is not that problematic. Since things need
untangling anyway, I would feel free to improve it if something is
done, but it's not much of a problem.

The problem is when there's a wildly different signature, or if args
change the return type structure, etc. So in this case, the problem is
really:

public function __construct(string $isostr, int $options = 0) {}

Which can't really be unified with the others very well.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Clone with

[Levi Morrison via internals]

On Mon, Apr 17, 2023 at 12:32 AM Máté Kocsis  wrote:
>
> Hi Everyone,
>
> Quite some time after mentioning the "clone with" construct the first time
> (at the end of the
> https://wiki.php.net/rfc/write_once_properties#run-time_behaviour section),
> finally I managed to create a working implementation for this feature which
> would make it possible to properly modify readonly properties
> while simplifying how we write "wither" methods:
> https://wiki.php.net/rfc/clone_with
>
> Regards,
> Máté Kocsis

I apologize if this has been discussed before, as I have fallen very
behind on internals discussions. I think it would be helpful to add an
example where the object being cloned accesses its properties.
Something like this:

   $b = clone $a with ["count" => $a->count * 2];

If this is not valid, or if it has unexpected behavior or semantics,
that should also be included in the RFC.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Add new function `array_group`

[Levi Morrison via internals]

On Tue, May 30, 2023 at 5:35 AM Boro Sitnikovski  wrote:
>
> Hello all,
>
> As per the How To Create an RFC instructions, I am sending this e-mail in 
> order to get your feedback on my proposal.
>
> I propose introducing a function to PHP core named `array_group`. This 
> function takes an array and a function and returns an array that contains 
> arrays - groups of consecutive elements. This is very similar to Haskell's 
> `groupBy` function.
>
> For some background as to why - usually, when people want to do grouping in 
> PHP, they use hash maps, so something like:
>
> ```
>  $array = [
> [ 'id' => 1, 'value' => 'foo' ],
> [ 'id' => 1, 'value' => 'bar' ],
> [ 'id' => 2, 'value' => 'baz' ],
> ];
>
> $groups = [];
> foreach ( $array as $element ) {
> $groups[ $element['id'] ][] = $element;
> }
>
> var_dump( $groups );
> ```
>
> This can now be achieved as follows (not preserving keys):
>
> ```
>  $array = [
> [ 'id' => 1, 'value' => 'foo' ],
> [ 'id' => 1, 'value' => 'bar' ],
> [ 'id' => 2, 'value' => 'baz' ],
> ];
>
> $groups = array_group( $array, function( $a, $b ) {
> return $a['id'] == $b['id'];
> } );
> ```
>
> The disadvantage of the first approach is that we are only limited to using 
> equality check, and we cannot group by, say, `<` or other functions.
> Similarly, the advantage of the first approach is that the keys are 
> preserved, and elements needn't be consecutive.
>
> In any case, I think a utility function such as `array_group` will be widely 
> useful.
>
> Please find attached a patch with a proposed implementation. Curious about 
> your feedback.
>
> Best,
>
> Boro Sitnikovski
>

I'm sorry if one of the many replies already mentioned this, but there
was a failed RFC for `array_group`:
https://wiki.php.net/rfc/array_column_results_grouping. Note that I
voted against it for technical reasons (the signature was just awful,
we can do better), but I am not against the idea of adding such helper
functions in principle.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] path_join function

[Mikhail Galanin via internals]

Hi,

Thank you for the proposal - it echoes somewhere inside me.

Just a little side-view of the problem...
Personally, I will be a fan of Kotlin-style Path API

E.g., the path is an object so we can get path items, and get
sub-path/resolve child nodes.
It appeared to be quite useful in practice.

Examples:
- https://stonesoupprogramming.com/2017/11/27/kotlin-path-interface/
- https://www.baeldung.com/kotlin/kotlin-path-api


On Wed, May 17, 2023 at 4:36 PM Tim Düsterhus  wrote:
>
> Hi
>
> On 5/17/23 16:54, p...@shyim.de wrote:
> > When you concat just the paths you have to think about:
> > - normalize string part to strip ending slash
>
> Why is it necessary to strip the ending slash?
>
> > - for windows compatibility you have to use DIRECTORY_SEPERATOR
> >
>
> I don't use Windows, but to the best of my knowledge, using the '/' is
> equivalent to the backslash. Is there a case where the difference matters?
>
> > I am really looking for your feedback, right now I have no “karma points” 
> > to create a RFC in the wiki :)
> >
>
> If you want to proceed with an actual RFC, the folks handing out the RFC
> karma would need your Wiki name.
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving a tmpfile()?

[Hans Krentel via internals]

On Sunday 07 May 2023 02:30:13 (+02:00), Dan Liebner wrote:

> > Why move the temporary file when it is already a temporary file, 
right?

>
> If you don't want to have to write the file again with a copy?

Then why create a temporary file first? ^^

Nevertheless, a fair point it seems, and then thinking that this is what 
often happens with tmpfile() on a Linux system:


- sys_get_temp_dir() is in the global file-system hierarchy and on a 
file-system of its own (tmpfs)


- a move (rename) operation across file system boundaries is a copy & 
delete operation


Given we're discussing file-system I/O to some extend here, and you're 
asking what could possibly go wrong: A lot when we don't expect it and then 
race conditions. Often we don't and even can't know in advance.


Therefore, if there is a need to create a temporary file in the first 
place, do it. If not, don't create it, as otherwise you have the copy 
already and this prevents you from learning if the file transaction really 
needs it to become robust or it is just extra I/O for nothing (and perhaps 
introduces places to error you actually don't want to deal with).



YMMV.


-- hakre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving a tmpfile()?

[Hans Krentel via internals]

On Saturday 29 April 2023 09:32:42 (+02:00), Dan Liebner wrote:

> Are there any inherent problems with moving a file created with 
tmpfile()?

>
> In practice, it seems that it can be done and the file will not be 
deleted

> after being moved and the file handle closed.

yes, not that it would be inherently wrong to do it that way, it is that 
tmpfile() already offers the file handle, so you can rewind() and put the 
contents in your destination file:



$destinationPath = tempnam(__DIR__, '.destination.');
$tempHandle = tmpfile();

# ... operate on $tempHandle ...
fwrite($tempHandle, "hello world\n");

rewind($tempHandle);
$result = file_put_contents($destinationPath, $tempHandle);
fclose($tempHandle);


Why move the temporary file when it is already a temporary file, right?

-- hakre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Final anonymous classes

[Levi Morrison via internals]

I am not sure about making them final by default. I think it's a more
consistent language design to allow `new final class()` as you
originally proposed. Although I don't know why anyone would want to
extend anonymous classes, we can see that people do, in fact, do it. I
don't see why we couldn't allow `new class() extends $someClass` in
the future to specifically allow them to do this. I mean, I'm not
going to lobby for it, I'm just pointing out that is more aligned and
consistent with other parts of the language, than to simply make it
final by default.

Cheers.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Hans Krentel via internals]

On Tuesday 02 May 2023 15:07:21 (+02:00), Rowan Tommins wrote:

> On Tue, 2 May 2023 at 13:20, Máté Kocsis  wrote:
>
> > Yes, I agree that the assert_options() name is at least weird but I
> > wouldn't like to
> > include changes into this RFC which are not strictly related to overloaded
> > signatures. Just like in case of implode(), the 1-parameter version of
> > assert_options()
> > could be added to the PHP 8.3/8.4 deprecations RFC though.
> >
> 
> 
> It *is* strictly related, though: the current function has two purposes:
> get an option, and set an option; the RFC proposes to split that into two
> functions, and there are three ways we can do that:
> 
> 1) Keep the current name for get, come up with a new name for set
> 2) Come up with a new name for get, keep the current name for set
> 3) Come up with new names for both get and set
> 
> I then looked further, and suggested:
> 
> 4) Deprecate the existing function, but do not create any new functions;
> instead, recommend ini_get for get, and ini_set for set
> 
> All four options are direct remedies to the overloaded signature, and I
> think due to the current unclear naming, options 3 and 4 are superior to
> options 1 and 2. Do you have a specific reason to prefer option 1?

I can't answer that question but checked especially option 4) as it looked 
promising to me.

In the overall context, let's not forget this note [1]:

> While assert_options() can still be used to control behaviour as described 
> above for backward compatibility reasons, PHP 7 only code should use the two 
> new configuration directives to control the behaviour of assert() and not 
> call assert_options().

That is zend.assertions and assert.exception only (of which only the second has 
a counterpart in ASSERT_EXCEPTION as the first can not be set at runtime).

That means: Before investing too much thought which of all the options, IMHO 
the general route should be to deprecate assert_options() overall to prepare 
its removal (and with it a good share of the assert.options).

>From signature / types perspective, ASSERT_CALLBACK option is not 100% 
>compatible w/ ini_get()/ini_set() as they don't support all types of the 
>callback pseudotype. but have not double checked this as I ran over the above 
>mentioned remark which I believe should be leading (the deprecation of the pre 
>PHP 7.0 assert/options alltogether).

With the PHP 8.0 release this got some traction (upgrade of the assert callback 
signature and ASSERT_QUIET_EVAL option seems to be gone (perhaps in alignment 
with the improvements in the error handler callback signature on the level 
parameter that is now the error type regardless of error_level())).

So perhaps this for the current RFC:

4) Deprecate the existing function, but do not create any new functions; 
instead, recommend the two configuration settings zend.assertions and 
assert.exception only, for those that can be set at runtime recommend 
ini_get()/ini_set(), for callback further investigate (does it still work?), 
for the moment I see no alternative to assert_options() for callback values not 
of type null or string (e.g. callabe array or callable object) as those are not 
supported by ini_get()/in_set().

-- hakre

p.s. thank you for creating this RFC and taking care.


[1]: https://www.php.net/manual/en/function.assert.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] VCS Account Request: ericmann

[Eric Mann via internals]

PHP 8.3 release management

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] PHP Technical Committee

[Levi Morrison via internals]

On Fri, Apr 28, 2023 at 4:01 AM Jakub Zelenka  wrote:
>
> Hi,
>
> The vote is now open for the RFC about introduction of the PHP Technical
> Committee:
>
> https://wiki.php.net/rfc/php_technical_committee
>
> Regards
>
> Jakub

Do we really need this level of bureaucracy? I mean... I know
someone's work got rejected and that wasn't a great situation, and I
feel for them because it was handled poorly IMO. But this committee
seems like a lot of work for... what? Being able to solve an
occasional disagreement? This seems like more work than it solves,
with some bad downsides if "the wrong people" get in there. You know,
the power-hungry egotistical kind of people.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Discussion] Callable types via Interfaces

[Levi Morrison via internals]

On Thu, Apr 20, 2023 at 9:57 PM Deleu  wrote:
>
>
>
> On Thu, Apr 20, 2023 at 8:23 PM Levi Morrison via internals 
>  wrote:
>>
>> I'm going to stop here. Two big things:
>>
>>  1. I think reducing verbosity can be left for the future. We don't
>> have to solve that right now.
>
>
>
>> What happens if I pass a short-closure?
>>
>> takeTwo(fn ($x, $y) => $x + $y);
>>
>> I would be annoyed if I had to write the type info, but particularly
>> the return type.
>
>
>  Sorry for the unhelpful email, but does anybody else see the irony here? 
> It's just too funny to not be mentioned 
>
> --
> Marco Deleu

Sure, I get that ^_^ But the difference is that there are quite a few
ways we can solve the first verbosity (allowing `fn` instead of
`callable`, allowing type aliases which could also be useful for
unions, etc), and only things that seem hard to solve the second one
(static type inference? delayed type checks?)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Discussion] Callable types via Interfaces

[Levi Morrison via internals]

On Thu, Apr 20, 2023 at 11:25 AM Larry Garfield  wrote:
>
> Hi folks.  This is a pre-discussion, in a sense, before a formal RFC.  
> Nicolas Grekas and I have been kicking around some ideas for how to address 
> the desire for typed callables, and have several overlapping concepts to 
> consider.  Before going down the rabbit hole on any of them we want to gauge 
> the general feeling about the approaches to see what is worth pursuing.
>
> We have three "brain dump" RFCs on this topic, although these are all still 
> in super-duper early stages so don't sweat the details in them at this point. 
>  We just want to discuss the basic concepts, which I have laid out below.
>
> https://wiki.php.net/rfc/allow_casting_closures_into_single-method_interface_implementations
> https://wiki.php.net/rfc/allow-closures-to-declare-interfaces-they-implement
> https://wiki.php.net/rfc/structural-typing-for-closures
>
> ## The problem
>
> function takeTwo(callable $c): int
> {
> return $c(1, 2);
> }
>
> Right now, we have no way to statically enforce that $c is a callable that 
> takes 2 ints and returns an int.  We can document it, but that's it.
>
> There is one loophole, in that an interface may require an __invoke() method:
>
> interface TwoInts
> {
> public function __invoke(int $a, int $b): int;
> }
>
> And then a class may implement TwoInts, and takeTwo() can type against 
> TwoInts.  However, that works only for classes, which are naturally 
> considerably more verbose than a simple closure and represent only a subset 
> of the possible callable types.
>
> The usual discussion has involved a way to specify a callable type's 
> signature, like so:
>
> function takeTwo(callable(int $a, int $b): int $c)
> {
>   return $c(1, 2);
> }
>
> But that runs quickly into the problem of verbosity, reusability, and type 
> aliases, and the discussion usually dies there.
>

I'm going to stop here. Two big things:

 1. I think reducing verbosity can be left for the future. We don't
have to solve that right now.
 2. I think there's another more important reason previous attempts
failed: they will inevitably burden the programmer without type
inference.For the moment, let's assume this signature:

function takeTwo(callable(int $x, int $y): int $c);

What happens if I pass a short-closure?

takeTwo(fn ($x, $y) => $x + $y);

I would be annoyed if I had to write the type info, but particularly
the return type.

Today, if I just used a static analysis tool, there's no problem:

/** @param callable(int $x, int $y): int $c */
function takeTwo(callable $c);
takeTwo(fn ($x, $y) => $x + $y);

 3. And another reason they failed: callables are going to want
generic types pretty commonly. Think array_filter, array_map, etc.

So, I think these brain dump RFCs are all focusing on the wrong problems.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Björn Larsson via internals]

Den 2023-04-13 kl. 10:38, skrev Mikhail Galanin via internals:

Hello good people,

Looks like another hot discussion on the list, isn't it?

Just wanted to share my notice about the initial idea.

7 years ago there were people considering NNTP as an option. Nowadays,
it's pretty clear that it isn't the way to go. It doesn't mean that
technology is bad (although, someone can share their negative
experience with that one) but instead, we hardly we can find a person
who still uses it.
If we switch to the News protocol, it is highly likely that we not
just won't engage new members but instead, we'll lose those who are
here.

Hem, I actually use the builtin NNTP client in Thunderbird connecting to 
news.php.net to follow PHP Internals. It's nice and it works :-)


Cheers //Björn L


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Moving PHP internals to GitHub

[Mikhail Galanin via internals]

Hello good people,

Looks like another hot discussion on the list, isn't it?

Just wanted to share my notice about the initial idea.

7 years ago there were people considering NNTP as an option. Nowadays,
it's pretty clear that it isn't the way to go. It doesn't mean that
technology is bad (although, someone can share their negative
experience with that one) but instead, we hardly we can find a person
who still uses it.
If we switch to the News protocol, it is highly likely that we not
just won't engage new members but instead, we'll lose those who are
here.

I reckon that this thread isn't about Github per se, it is rather a
shout that the technology is declining. It happens slowly, hence it's
hard to notice if you use it but suddenly you realise that people
don't even know what a "mailing list" is.

If we look at other projects (I will exclude Linux here: they still
discuss patches over emails), many of them started using online tools
(links below):

* Firefox devs actively use Matrix (a free platform) as well as maillist
* Kotlin doesn't use mail at all, they opted in using Slack + bug
tracker + KEEPs (something like RFCs).
* Docker does have a mailing list but it contains only spam over the last year

PHP switched to Git and Github as the code repository, I believe for
the same reason: it is a more popular and well-known tool these days.
So, the tooling for me isn't the toy with new fancy features
(personally, I'm happy with SVN and email: I'm an old codger), it's
rather about engaging new people, and making their life simpler.

Moreover, if we don't want to make a sharp move, we can try
introducing a new tool and see the activity there (or even introduce
this for other topics, like "PHP users", "Extension developers",
etc...).


Links:

https://wiki.mozilla.org/Matrix
https://github.com/JetBrains/kotlin/blob/master/docs/contributing.md
https://groups.google.com/g/docker-dev


Not trying to force any decision, just thought this was something that
could be considered as well.
Thanks and have a great day.

On Wed, Apr 12, 2023 at 2:53 PM Alex Wells  wrote:
>
> Hey.
>
> PHP currently uses internals@lists.php.net for communication. That includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
>
> While emailing definitely works, it's not the best UX out there. Here are
> some immediate flaws which make the process harder than it should be:
>  - having to subscribe to a mailing list to even see the discussions
>  - supporting public archives such as externals.io to expose discussions to
> the public for those who aren't subscribed and keep historical data
>  - having to learn the specific, uncommon rules of replying: bottom
> posting, word wrapping, removing footers. It's not to say any of those
> rules are complex or hard to follow; it's that they're basically
> inapplicable outside of emails, so they're usually not known by newcomers.
> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.
>  - no way of editing a message. Mistakes will always be made, so being able
> to quickly fix them would be nice
>  - no formatting, especially code blocks. Sure, they are possible through
> HTML, but there's no single common way which all of the emailing clients
> will understand - like Markdown
>  - no reactions - it's hard to tell whether something is supported or not.
> This includes both the initiative being discussed and the replies that
> follow. Sure, you can usually kind of judge the general narrative based on
> the replies, but it's not always clear what's in favor. There are usually
> many divergent branches of discussions and it's unknown what's supported
> the most.
>
> Based on those issues and PHP, I propose moving the discussions elsewhere -
> to some kind of modern platform. Since this is quite a big change in the
> processes used, I imagine an RFC would be needed. But before I do that I
> want to measure the reactions. If it goes well, I'll proceed with an RFC
> draft.
>
> There are basically two choices here - a messenger-like platform (i.e.
> Slack, Teams) or a developer focused platform like GitHub. While messengers
> certainly work, they're more focused on working with teammates rather than
> actual discussions. They usually don't have a simple way to navigate
> publicly and are poor at separating multiple topics into threads. Some
> projects use them for that purpose, but it's usually a worse experience
> than what GitHub provides.
>
> GitHub is already used by PHP for both the source code and the issues, so
> that is a good candidate, especially since it's a platform designed to
> handle cases like this. Also, that should be a much easier transition now
> that the source and issues were moved to Gi

[PHP-DEV] Re: Future stability of PHP?

[Björn Larsson via internals]

 if its available). In 
the end

I found a solution using an anonymous class that implements the Iterator
interface. But this is different between PHP 7 and 8 (because of the 
mixed type)
so I had to implement my first version switch in PHP… which felt quite 
weird. I
usually only have to do that in C to support corner cases for quirky 
compilers.

So this spooked me quite a bit.

Sorry for the long wall of text.

Happy programming
Stephan


Hi,

My 50c and a bit casual reflection on that is:
- When we upgraded a PHP 5.2 codebase to first 5.6 and later to 7.0 it 
was a breeze. Also the open source libraries that we used was straight 
forward to migrate.
- Now when going from 7.4 that we still use today to 8.x it was a longer 
process also because we need to wait out the open source libraries to 
migrate. Today we just need to gather ourselves and do the effort, so 
our codebase is ready for 8.x migration.
- The the PHP 7.x release has really provided a tremendous value in 
terms of new features, which also the 8.x serie does, but the 
deprecations are more cumbersome.


So I think there is a need here to:
- Not just look at deprecations on one release, but one should instead 
look at them for a complete release cycle for all 8.x releases and say 
at some point that the deprecation quota is filled up, i.e. no more 
deprecations for 8.x.
- And when piling up these deprecations that will hit harder in 9.0 one 
have to take into account what added value will 9.0 bring. There has 
been some old RFC's that was rejected and maybe these can be brought to 
life again for 9.0 to bring added value besides completely new features. 
E.g. one of my favourites was the Pipe operator RFC.


Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] PHP Technical Committee

[Björn Larsson via internals]

Den 2023-04-07 kl. 12:58, skrev Jakub Zelenka:

Hello,

Here is a proposal for an introduction of the PHP Technical Committee:

https://wiki.php.net/rfc/php_technical_committee

The main purpose of this RFC is to have better decision process when
technical conflicts between developer arise.

This was created in collaboration with other people involved in PHP core
development and the PHP Foundation. Larry has done a lot of work in
rewording the text and he is also a co-author of this RFC.

Feel free to comment here or if you have just some wording suggestions
there is also a PR in my util repository for easier collaboration on the
text: https://github.com/bukka/php-util/pull/1 . So feel free to comment /
send suggestion there as well.

Regards

Jakub


I think this is a very good initiative, so good luck with it!

Question:
- Is this something that could be used to point out general areas for 
improvement of PHP, e.g. like a roadmap/wishlist for 9.0?


Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

[Hans Krentel via internals]

On Monday 10 April 2023 14:17:04 (+02:00), G. P. B. wrote:

> Hello Internals,
> 
> Dan and I would like to propose a new core autoloading mechanism [...]

>
> The existing SPL autoloading functions would become aliases to the new 
Core

> ones and will continue to work without any migrations needing to be
> performed.
> 
> Hope to hear your opinions about this!


Thanks for taking the time for this, I only quickly skimmed over it, an 
insightful reading already.


What I wondered about and which made me writing a reply on the list is in 
retrospect of the times class autoloading came in, which is also closer to 
the time when namespaces were introduced. It was the latter which brought 
us `class_alias()` [0] and I've used it often in code migrations (is 8.3 
the new 5.3? would be easy to remember.).


So I'd love to see some commentary on a `function_alias()` if now function 
autoloading is considered to come in, as I can imagine this has similar 
effects for how you'd like to namespace PHP code with the new, better 
functionality of function autoloading and access to an alias table from PHP 
"userspace" I'd consider helpful then.


Best,

-- hakre

[0]: https://www.php.net/class_alias

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Future stability of PHP?

[Nick Dickinson-Wilde via internals]

 Original message From: Andreas Leathley  
Date: 2023-04-11  07:19  (GMT-08:00) To: internals@lists.php.net Subject: Re: 
[PHP-DEV] Future stability of PHP? On 11.04.23 15:56, Jeffrey Dafoe wrote:>> So 
turn off the deprecation warnings for now. They're just a heads up that>> 
behaviour is going to change in the future, with PHP 9.>>>> I doubt you'd 
prefer not to be aware of the change well in advance.> Oh, absolutely. We run 
those "on" in our dev and QA environments but off in production. I'm referring 
to the work required to mitigate the removal once we plan to migrate to 9. 
Although our codebase is old, we are funded to keep the code up to date. It's 
just that a handful of the changes, such as removing dynamic properties, has 
such a large impact and such a questionable benefit.Removing dynamic properties 
has multiple benefits - from avoidingtypos/mistakesAs a heavy php user but not 
core contributor... removal of dynamic properties is just simply fantastic. 
Dynamic properties hide so many horrors and were the cause of the singular most 
difficult to debug issue I've ever dealt with that was easily 
replicated.NickNick Dickinson-Wilde
  he/him [EN]| il/lui [FR]
  NickDickinsonWilde.ca
  | 250-893-3080 (cell) (7am-10pm) - Pacific Date Time
  Personal: Twitter,
  GitHub, Drupal.org.
  ---

Re: [PHP-DEV] Array spread append

[Hans Krentel via internals]

On Saturday 08 April 2023 22:17:14 (+02:00), Niels Dossche wrote:

> However, I think it might be worth adding an optimization for the most 
common $x = array_merge($x, ...) case.


If so, then syntax wise I'd throw that suggestion in the ring:

$x[] = ... $y ;

This would allow to adopt existing code (from push one to splat from 
iterable); is short; the splat operator in front of where I'd expect it and 
the existing semantic of $x[] "append operator" (a.k.a. "push").


Not the idea for multiple operands thought, this might be a bigger upgrade:

$x[] = ... $y , $y[0], ... $z ;

as it would also require to work without the splat operator for reasonable 
symmetry:


unset($x);
$x[] = 1;
$x[] = 2, 3;
$x[] = ... range(4, 6), 7;

Semantics still look clear to me, but I can't write an implementation.

And optimization wise ArrayAccess could benefit from a specialization form 
then, e.g.  ::offsetPush($offset, iteratable $values) which should be 
optional, or perhaps even with offsetSet($offset, mixed ...$values) as an 
optional upgrade if PHP semantics allow such changes.


Just my 2 cents.

-- hakre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Release Managers for PHP 8.3

[Eric Mann via internals]

I had volunteered in a previous cycle but, sadly, lost in the voting 
round. That said, I'm still eager to be more heavily involved and up for 
the challenge (both for the immediate process and for any long-term 
support beyond the dates listed in the existing todo.


I've been working with PHP in userland since 2005 and dabbling in 
internals (mostly to understand FFI and interoperability) since 2016. 
I'm not a C guru as in I can't reliably _write_ greenfield C code. But I 
have worked with and on C/C++ teams and am well adept at groking 
existing code, hunting for bugs, and ensuring that submitted code does 
what it claims to do.


It would be an honor to even be considered for this role and I'd love to 
earn your support!


~Eric Mann

On 3/1/23 12:20 PM, Sergey Panteleev wrote:

Hi all,

It's time to start the process of finding and electing RMs for the next minor 
PHP release.

We are looking for three souls to take on this role. Whomsoever is elected will 
be guided and helped by the current, as well as previous RMs and the excellent 
documentation in release-process.md [1].

Candidates should have a reasonable knowledge of internals (without necessarily 
being a C guru), be confident about merging pull requests without breaking 
backward compatibility, doing triage for bugs, liaising with previous release 
managers, and generally getting the branch in good shape, as these are among 
the activities you will be undertaking as release manager.

Notably, at least one of the volunteers must be a "veteran" release manager, 
meaning they have participated in at least one release of PHP in the past. The other may 
be an additional veteran, or more ideally, someone new to the RM role (in order to 
increase our supply of veteran RMs).

Please put your name forward here if you wish to be considered a candidate. An 
initial TODO page has been added to the wiki and contains provisional dates for 
GA and pre-releases [2].

[1]https://github.com/php/php-src/blob/master/docs/release-process.md
[2]https://wiki.php.net/todo/php83

Let's all make PHP awesome!
Pierrick Charron, Sergey Panteleev & Ben Ramsey



--
Security Principles for PHP Applications 
<https://www.phparch.com/books/security-principles-for-php-applications/>

*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA <https://keybase.io/eamann>
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com <https://eamann.com>
ttmm.io <https://ttmm.io>
Twitter icon <https://twitter.com/ericmann> LinkedIn icon 
<https://www.linkedin.com/in/ericallenmann/>

Re: [PHP-DEV] Deprecate ldap_connect with host and port as separate arguments

[Levi Morrison via internals]

On Fri, Jan 27, 2023 at 8:54 AM Larry Garfield  wrote:
>
> On Fri, Jan 27, 2023, at 3:00 AM, Andreas Heigl wrote:
> > Hey Folks.
> >
> > I think it would be a good idea to deprecate calling ldap_connect with 2
> > parameters host and port.
> >
> > Wait: What?
> >
> > Currently there are three ways one can call ldap_connect.
> >
> > 1. With a string $ldap_uri
> > 2. With a string $host and an int $port,
> > 3. With even more parameters for those that did compile PHP with OracleLDAP.
> >
> > The 3rd way of calling it is not even documented in the docs as it is a
> > very niche edge-case that would only confuse most people.
> >
> > The 2nd way of calling the function is based on the since some years
> > deprecated underlying ldap_open function. Internally we already moved to
> > the underlying ldap_initialize-function that requires passing an
> > LDAP-URI. For that we are already converting the passed host and port
> > into an LDAP-URI of the form 'ldap://$host:$port'.
> >
> > This already illustrates one of the issues that this way of calling the
> > function implies: It is not possible to use ldaps as a schema using that
> > way of calling ldap_connect as it will always use ldap as schema. No
> > matter which port is passed.
> >
> > A second reason why I think we should deprecate calling ldap_connect
> > with two parameters is, that it does not allow one to pass multiple
> > ldap-servers as it is possible using the LDAP-URI.
> >
> > This is for sure a BC-break but in my opinion a rather small one as
> > there are not many users actually using it and there is a clear and easy
> > migration path for those that use it: Instead of calling
> >
> > ldap_connect($host, $port)
> >
> > one calls
> >
> > ldap_connect("ldap://$host:$port??369;)
> >
> > Also most of the users should not be affected at all as they are using
> > 3rd party libraries that are already only using an LDAP-URI when calling
> > ldap_connect like Laminas\Ldap or Symfony\Ldap
> >
> > The documentation at https://www.php.net/ldap_connect also explicitly
> > states (for some time by now) that using host and port is considered
> > deprecated.
> >
> > Named parameters btw also only support ldap_connect(uri:
> > 'ldap://example.com') and ldap_connect(host:'example.com', port:369)
> > will throw an error.
> >
> > There already is a PR open[1] that implements the deprecation so that
> > for the upcoming PHP8 releases each call to ldap_connect with 2
> > parameters would emit a deprecation message so that people have enough
> > time to adapt their code before we can actually remove using two
> > parameters in the next major release.
> >
> > Thanks for your comments.
> >
> > Cheers
> >
> > Andreas
> >
> > [1] https://github.com/php/php-src/pull/5177
>
> This would require an RFC, obviously, but it seems reasonable to me.  
> "Variable meaning parameters" was always a bad idea, and cleaning them up is 
> a good idea.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

I disagree that this needs an RFC. The docs have long-said it's
deprecated; adding a deprecation message _in code_ to match shouldn't
require an RFC.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

[Levi Morrison via internals]

It seems to me that if you truly want to clean up this specific part
of the language, you are going to have to play the long game:
 1. New functions are added for the perl behavior of string increment
and decrement. No warnings are given in code, but call-outs are made
in upgrading and other documentation about this behavior changing.
Note that in the past I would have used an E_STRICT for this, but
people seem opposed to adding new E_STRICT warnings.
 2. In the next minor version, we add a warning about the behavior
when string increment/decrement is used.
 3. In the next major version, we finally clean up the behavior.

But this gets muddy if we do PHP 8.3 for step 1, and then we decide to
go for PHP 9.0 instead of 8.4, and it messes with the "ideal" cycle.

Note that I support this sort of plan, and would support it for
cleaning up many other parts of PHP as well. It's just unfortunate it
takes so long, but that's how it goes sometimes :/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators

[Björn Larsson via internals]

Den 2023-01-18 kl. 13:22, skrev G. P. B.:

On Tue, 17 Jan 2023 at 18:28, Mark Baker  wrote:


On 17/01/2023 17:28, Craig Francis wrote:

I've seen this used a few times, e.g. starting with a numerical value

(Passport number, NHS number, Social Security Number, Date of Birth
20230117), and the developer simply appends an incrementing letter on the
end to get a unique reference; e.g. a person having multiple assessments...
especially if it's more than 26 (A-Z), and you need to move to multiple
letters, which `chr(90 + 1)` cannot help you with.

Being able to increment alpha strings is incredibly useful when working
with Excel spreadsheets (as I do on a daily basis), because the column
Ids match this pattern; and I would hate to see this deprecated. Having
to replicate that logic for traversing column Ids in userland code would
be inconvenient (to say the least), would affect many of the users of my
libraries, and would have a performance impact on my libraries. If
anything, I'd rather like to see the decrement operator work with alpha
strings as well for more consistency.

I don't have the karma for a vote; but if I did then it would be a "No"
for this alone, because I can see the problems that it will cause me and
the users of my libraries.



That said, I appreciate that incrementing some strings can be a bit

unusual (e.g. "A9" to "B0", vs "A 9" to "A 0").

Agreed. While incrementing works in a very logical manner with mixed
alphanumeric strings, it's not well documented behaviour, and most
developers take a long time before they understand what it's actually
doing. While there might be use cases for incrementing alphanumerics, I
suspect that it would be better implemented in the business logic of an
application, because the component parts of that string are likely to
have business meaning; and also to provide better code readability.



I appreciate being shown concrete cases about the useful ness of this
operation.
The reason I didn't go with adding support for decrementing alphanumeric
strings is that it was unanimously rejected.
However, if Rowan's suggestion of adding
string_increment()/string_decrement() with more rigorous behaviour (that we
can flesh out together) would be part of this proposal, would you be more
inclined to accept deprecating ++ from performing this feature?

I truly believe having $v++ behave like $v += 1 and $v-- behave like $v -=
1; is something to strive for *because* it allows us to remove one
dedicated type juggling context people need to be aware of and simplifies
the overall semantics of the language.
Keeping support for string increments means that one cannot interchange $v++
and $v += 1 and that one needs to be aware about using it when a value
might hold a string.
As such, if it needs to remain its own type juggling context, the question
is why not make it stricter by having it warn and then throw a TypeError on
bool, reopening the can of worms that is the null handling between both
operators and what to do with the empty string case.
These questions are already answered by making those operators behave just
like addition/subtraction.

My order of preference for the semantics are as follows:
1. The behaviour described in the RFC (with or without function for string
in/decrement)
2. (with a massive gap, but I could live with it) adding support for string
decrements and tiding up the behaviour of the alphanumeric string to make
it stricter and less error-prone.
3. The current asymmetry (again with a massive gap between this and option
2)

But because option 2 seems out of the question due to the unanimous
rejection of https://wiki.php.net/rfc/alpanumeric_decrement, the only
viable options to me seem like 1 and 3.
As I hate option 3 I am pushing for option 1 as I think it has various
benefits.


Since the alpanumeric_decrement RFC was rejected january 2014 9 years ago,
could it be an option to bring it up again in conjunctione with your RFC?

Maybe the added value of your RFC could swing the opinion. I mean there has
been RFC's that required multiple tries to fly.

Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC: rules for #include directives

[Levi Morrison via internals]

As commented yesterday on one of the PRs, I strongly agree with the
cleanups. Our code has implicit dependencies and if you reorder the
includes in the same file, you can break builds. That shouldn't ever
happen.

I also agree that dtrace breaking is a failure of CI and testing, not
necessarily the patch (I haven't reviewed that PR carefully, maybe
there was some carelessness but if it's not tested, it's hard to blame
anyone).

Lastly, I do not care for the comments which explain why a header is
included. My experience is that these comments bitrot quite quickly.

Overall, I hope we can resume this effort.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] base64url format

[Eric Mann via internals]

I'm in support of such a feature, but would strongly advocate for an 
additional parameter to flag whether or not to include the trailing `=` 
pad. The trailing pad is optional according to RFC 4648, so I think 
leaving it off by default would be the ideal use case, but an optional 
`include_padding` flag or something along those lines would be helpful.


On 1/9/23 10:49 AM, Sara Golemon wrote:

I've been working with JWTs lately and that means working with Base64URL
format. (Ref:https://www.rfc-editor.org/rfc/rfc4648#section-5  )
This is essentially the same thing as normal Base64, but instead of '+' and
'/', it uses '-' and '_', respectively. It also allows leaving off the
training '=' padding characters.

So far, I've just been including polyfills like this:

function base64url_decode(string $str): string {
 return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 -
(strlen($str) % 4)) % 4, '='));
}

function base64_encode(string $str): string {
 return rtrim(strtr(base64_encode($str), '+/', '-_'), '=');
}

These work fine, but they create a LOT of string copies along the way which
shouldn't be necessary.
Would anyone mind if skipped RFC and just added `base64url_encode()` and
`base64url_decode()` to PHP 8.3?

Can hold a vote if anyone objects, but this seems fairly non-controversial.

-Sara



--
Security Principles for PHP Applications 


*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA 
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com 
ttmm.io 
Twitter icon  LinkedIn icon 

Re: [PHP-DEV] Microseconds to error log

[Mikhail Galanin via internals]

Hi Derick, Jakub and the team,

Thank you so much for your input. Sorry for being so slow with this --
I haven't forgotten, it's just unfortunately, I'm not capable to
handle all the things going around but I keep trying :)

I did some research about why we keep using plain log files and our
folks basically follow what Jakub said - we have our custom log
collector (similar to Scribe, Fluentd and others) which has quite
complicated routing rules and it was pretty straightforward to use
files but adding Syslog adds undesirable complexity to this system.
Although, it certainly doesn't look impossible.

Speaking about backward compatibility stuff - I can think of another
option, to postpone such a change till PHP v9.0, where we tend to
introduce breaking changes. We are not a startup anymore - can wait
for a couple of years.

I saw the suggestion to draft an RFC for this to thoroughly walk
through the question. I'm pretty open to this but it'll take a lot of
time. So guys, do you feel it's feasible to do? I can imagine some
people don't want to be harsh to say "please, stop this nonsense" :)
I can see that this change might not bring a lot of value and appeared
to be controversial so I'm fine to stop - we can keep this as our
private patch. But if someone feels it might be something good, I can
proceed with the RFC or something.

Thank you for your patience so far.



On Tue, Nov 29, 2022 at 11:43 AM Jakub Zelenka  wrote:
>
> On Mon, Nov 28, 2022 at 4:13 PM Derick Rethans  wrote:
>>
>> On Fri, 21 Oct 2022, Mikhail Galanin via internals wrote:
>> > Looking into the future, probably we would like to have this format
>> > configurable, if so it looks easy to do but still I can't see an easy
>> > way to handle the microseconds issue.
>>
>> Making things configurable requires an ini setting, which we generally
>> don't like to add. It wouldn't really work in this situation, as
>> warnings/errors happen either before or during INI file parsing, meaning
>> that it can't (yet) use the new format.
>>
>
> I'm not sure I understand this because error_log itself is already 
> configurable using INI so obviously if the file path is specified there, then 
> the logged time format should be the same if configured in ini. By default 
> there is no error log so errors that happen before should not be logged 
> anyway. Or do I miss anything?
>
>>
>> > Could you please help me to find the right way and share your thoughts
>> > about this topic (maybe there are strong objections against such a
>> > change)?
>>
>> I don't think we should change anything in PHP. Instead, use your
>> system's syslog. You can configure PHP to send all warnings to syslog by
>> setting "log_errors=1 error_log=syslog" in PHP.ini. In order to separate
>> out just the PHP issues, you can also set "syslog.facility=local1" (or
>> any other local).
>>
>> On Unix systems, you can configure syslog to add milliseconds to the log
>> file messages. See  https://askubuntu.com/a/1266114
>>
>> If your system already uses systemd and journald, then you don't have to
>> use any configuration settings, and you can query the journal with:
>>
>> journalctl -o short-iso-precise -r --facility=local1
>>
>> A PHP warning would show up in there, with something like:
>>
>> $ sudo journalctl -o short-iso-precise -r --facility=local1
>> 2022-11-28T16:06:53.862980+ gargleblaster php[3143059]: PHP Warning:  
>> Undefined variable $fasd in Command line code on line 1
>>
>
> It is not always practical to use system log for PHP especially for users 
> using more than one FPM pool. Log files also offer some advantages like 
> easier export and post processing so I think there is still place for log 
> files and we should support the users that still use them which includes new 
> features like this one.
>
> Cheers
>
> Jakub

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Microseconds to error log

[Mikhail Galanin via internals]

Hello good people,

(really hope I'm writing into the right thread this time).

I updated the patch considering the thoughts from this thread. Thank
you all for being so much responsive and helpful!

Meanwhile, there are two changes:

* Added function `php_format_timestamp' that takes microseconds part,
`php_format_date' remains unchanged to keep backward compatibility.
* Added INI `error_log_usec` = on|off (off by default) that changes
the timestamp.


Questions I have at the moment:

1. Naming (the most difficult part of our job, yeah) - does anyone
feel that they could suggest something better? Maybe someone can think
up something better, more clear/consistent with other parts of the
codebase?

2. The INI-thing. When initially I mentioned being configurable, I
realised that it could've been perceived in many different ways:

- we can enable/disable the microseconds
- we can choose from a pre-defined list of formats (PHP7, PHP7 + msec,
PHP7+ usec, ISO8601, ISO8601+usec, etc...)
- we also might want to use an Apache/HTTPd-like approach, e.g.
"[${time:format} $pid $hostname] $error_message"

Or, once we enable microseconds, we can switch to the ISO format, for
example (no, I don't like this approach but if we change the setting
name it might be not that confusing)

What do you think?

On Mon, Oct 31, 2022 at 10:16 AM Craig Francis  wrote:
>
> On Sun, 30 Oct 2022 at 17:42, Rowan Tommins  wrote:
>
> > In case of any confusion, I think this should be configurable as
> > "include microseconds: on / off", not configurable as "enter date format".
> >
>
>
> Any reason it can't be configured to use ISO 8601?
>
> Apache 2.4 allows you to use `LogFormat "...
> [%{%Y-%m-%dT%H:%M:%S}t.%{msec_frac}t] ..." format_name`
>
> https://httpd.apache.org/docs/trunk/mod/mod_log_config.html
>
> And MySQL uses "-MM-DDThh:mm:ss.uu":
>
> https://dev.mysql.com/doc/refman/8.0/en/error-log-format.html#error-log-format-system-variables
>
> When I'm doing some quick log checking, I often forget that PHP uses a
> different date format... admittedly, it can help having the month spelled
> out, so no one accidentally thinks it's the American format :-)
>
> Craig

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: RFC [Discussion]: Randomizer Additions

[Joshua Rüsweg via internals]

Hi


You can find the RFC at:

https://wiki.php.net/rfc/randomizer_additions

Proof of concept implementation is in:

* https://github.com/php/php-src/pull/9664
* https://github.com/php/php-src/pull/9679


we believe we resolved all open questions with the RFC and there was no 
recent feedback with regard to the newest naming. Therefore we plan to 
open voting on Wednesday, November, 9th, unless someone speaks up now 
:). There will be two votes, one for the random string generation, one 
for the floating point generators. Voting will run for two weeks, a 2/3 
majority will be required (as with all votes). You can find the details 
within the RFC in the "Proposed Voting Choice" section: 
https://wiki.php.net/rfc/randomizer_additions#proposed_voting_choices


The PoC implementations have been updated with the latest RFC changes, 
they will be cleaned up after the vote concludes.


Cheers

Joshua Rüsweg

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] ARRAY_UNIQUE_IDENTICAL option

[Levi Morrison via internals]

A bit off topic, but not entirely:

In my opinion, adding another flag isn't the _real_ fix. Any function
which does comparisons should take a callable for users to provide any
comparison they wish. An iteratively better API would be:

function array_unique(list $array, callable(T $a, T $b): int
$comparator);

Of course, there are other things like instead of using int for `0`,
`-1`, `1`, we could have used an enum but we don't have one today. I
just mean the core idea of taking callable is better than mucking
around with flags while also allowing for custom comparison. Note that
it doesn't necessarily prevent optimizations either. For instance, if
they had passed `php_compare` or some function which represents `$a
<=> $b`, we could identify that just as we identify a specific flag
and take an optimized pass.

Note that as enums aren't "comparable" directly, we could have
provided a custom comparator in this case, no "fix" necessary in core.



Of course, this complaining doesn't fix the situation we are in. My
first impression is that might be better to provide one or more
alternative functions and to deprecate `array_unique`.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] ReflectionType for iterable / PHP 8.2

[Levi Morrison via internals]

FYI, it is also noted in the [UPGRADING][1] file:

> - Core:
>  . The iterable type is now a built-in compile time alias for 
> array|Traversable.
>Error messages relating to iterable will therefore now use 
> array|Traversable.
>Type Reflection is preserved for single iterable (and ?iterable) to produce
>a ReflectionNamedType with name iterable, however usage of iterable in
>union types will be converted to array|Traversable

  [1]: https://github.com/php/php-src/blob/PHP-8.2/UPGRADING

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC [Discussion]: Randomizer Additions

[Joshua Rüsweg via internals]

Hello!

[As Larry kindly pointed out to me, I only sent the email to Larry and 
not to the mailing list.]



"Alphabet" here still, to me, implies a character set, not a byte stream.  Maybe 
getBytesFromString?  getBytesFromList?  getBytesFrom() (because you're getting it "from" 
the string that's provided, so you don't need another noun there.)?

I'm not opposed to the functionality, but "alphabet" doesn't seem like the 
right word for it.


I'm not really happy with the name either and was hoping for some 
suggestions. `getBytesFrom` sounds incomplete to me. `getBytesFromList` 
sounds to me as if an array is being passed there and not a string. 
`getBytesFromString` sounds good to me, though. Better than 
`getBytesfromAlphabet`!


Cheers

Joshua Rüsweg

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: RFC [Discussion]: Randomizer Additions

[Joshua Rüsweg via internals]

Hi


You can find the RFC at:

https://wiki.php.net/rfc/randomizer_additions


Tim Düsterhus and I have updated the RFC and have broadly adopted the 
proposals.


Firstly we have renamed the `getBytesFromAlphabet` to 
`getBytesFromString` as Larry Garfield suggested.


Secondly, we have extended the getFloat method with a parameter that 
specifies which type of interval should be generated (Open, Closed, 
Right Half-Open and Left Half-Open).


Are you happy with the enum names? Have you any other suggestions?

Cheers

Joshua Rüsweg

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: Expanded iterable helper functions and aliasing iterator_to_array in `iterable\` namespace

[Levi Morrison via internals]

> > There's other functionality that I was less certain about proposing, such 
> > as `iterable\keys(iterable $iterable): array`,
> > which would work similarly to array_keys but also work on Traversables 
> > (e.g. to be used with userland/internal collections, generators, etc.)
>
> I assume this doesn't care about key uniqueness -- it takes the keys
> and makes them values, in the same order they were returned?
>
> In any case, I don't think this should return an iterable, not array,
> to allow for lazy operations in a chain, while also allowing for using
> an array as an optimization.

Oops, I meant to say I think this should return an iterable, not an array.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: Expanded iterable helper functions and aliasing iterator_to_array in `iterable\` namespace

[Levi Morrison via internals]

ver)`

This general feedback also applies to `iterable\find()`.

> I also wanted to know if more verbose names such as find_value(), 
> fold_values(), any_values(), all_values() were generally preferred before 
> proposing this,
> since I only had feedback from a small number of names. My assumption was 
> short names were generally preferred when possible.

I like the verbose names when there are variants, for instance `fold`
and `fold_with_keys` (where we provide both key and value). I
definitely do not like it when we change function signatures of
callbacks based on `flags` parameters like some PHP functions do
today.

Phew, I'm not sure the mailing list is the best way to the tidbits of
the APIs! In any case, I strongly support the direction.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Adding the OpenSSF Scorecards GitHub Action

[Pedro Nacht via internals]

Tim,

Thank you for the feedback, I'll be sure to pass it on to the Scorecards
team.

And if there's interest, I'll happily fix that small inconsistency in the
labeler.yml permissions.

And with this I believe I'll go ahead and close the GH issue and PR. I'll
stay in the mailing list for a few more days if anyone has any further
questions or comments.

Truly thank you everyone for your time,
Pedro

On Thu, Oct 27, 2022 at 7:32 PM Tim Düsterhus  wrote:

> Hi
>
> I'm also highly sceptical of wasting CPU time on such an automated scan.
>
> Once the few universally useful low-hanging fruits are picked, only the
> non-low-hanging fruits remain by definition. If they are not implemented
> reasonably timely then there is likely a reason for that, be that
> technical or processual. Then there is also no need for the reports to
> sit within the Security tab forever and also no need for them to be
> rechecked by maintainers regularly. Then there's also the issue of
> what's effectively false-positives (see below) which further distract
> from whatever benefit to the automated scan there might be in the first
> place.
>
> On 10/24/22 19:05, Pedro Nacht via internals wrote:
> > - set GitHub workflow dependencies to adopt hash-pinning instead of
> > major-version pinning. This is to eliminate the risk of tag-hijacking
> > attacks where a malicious commit is published to an Action you rely
> on and
> > the tag is then recreated to point to that malicious commit.
> Dependabot or
> > Renovatebot (which the tool also recommends adding to the project)
> can then
> > be used to keep your dependencies up-to-date.
>
> Is there any practical benefit to this when all the workflows are
> read-only with regard to the repository contents?
>
> On the contrary I believe that hashes make it much harder to verify
> which major version of an action is used, e.g. to check the changelog
> for any relevant breaking changes before upgrading the action.
>
> >- set all GitHub workflows with top-level read-only permissions. It
> >recognizes that almost all PHP's workflows have top-level read-only
> >permissions, but points out that github/workflows/labeler.yml doesn't
> >(though it does have job-level contents read-only permissions).
>
> I consider that a false-positive then, because the workflows *is* secure
> in practice. No need to waste maintainers time with the busy-work of
> moving the 'permissions' section around.
>
> I can see the small benefit of consistency across workflows, though and
> will likely send a PR to unify this if no one beats me to it.
>
> >- and yes, enforce Code-Review and maximal Branch-Protection. I
> >understand this would be quite impactful on the project's current
> workflow,
> >but it's the sort of thing that would mitigate the sort of
> >attack @ricardoboss mentioned in the linked GH issue. Whether the
> costs are
> >worth the benefit is a question you are all certainly better equipped
> to
> >determine than me.
>
> I would hope none of the core contributers disputes the benefit of code
> review, so … there is no need for a tool to tell them what they already
> know.
>
> > However, others offer more continuous monitoring in case there's an
> > accidental slip-up: if any new workflows are added to the project in the
> > future without minimal permissions or without pinning dependencies, for
> > example, the Action will update the Security Dashboard with an alert.
>
> The repository is already configured to only grant "read" permissions to
> the workflow by default using this setting:
>
>
> https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-the-default-github_token-permissions
>
> I believe this is a much more reliable solution than expecting the
> maintainers to regularly check the Security Tab and noticing that a new
> warning popped up.
>
> The proposed automated scanner does not appear to detect that this
> setting is enabled, thus effectively making the labeler.yml report a
> double false-positive.
>
> Best regards
> Tim Düsterhus
>

Re: [PHP-DEV] Microseconds to error log

[Mikhail Galanin via internals]

Hello everyone,

I tried following Derrek's approach (to introduce a new function).

A couple of considerations:

We used to have some pain when this format changed last time (I can't
remember details, unfortunately) but I don't feel like making an
option to provide backward compatibility is a good idea. Early or
lately, we will need to drop this compatibility and the users face
absolutely the same issue.

I hear people don't want to have this format configurable -- I tend to
agree that it's a bit overcomplication.

I'm not sure if I'm ready to switch to ISO8601 but if we have a
consensus here, I'm open to updating the patch. Basically, I'm open to
everything, please share your opinions.

Pull-request: https://github.com/php/php-src/pull/9844

On Fri, Oct 21, 2022 at 11:46 AM Rowan Tommins  wrote:
>
> On 21 October 2022 08:47:30 BST, Mikhail Galanin via internals 
>  wrote:
> >Basically, we have quite a high-loaded environment and we really want
> >to see timestamps containing milli-/microseconds in our logs.
>
>
> I'm not knowledgeable enough to comment on the implementation details, but 
> from a user point of view I agree the feature would be useful. It would 
> definitely need to be behind an ini setting, though, to avoid existing log 
> parsers failing unexpectedly on the new format.
>
> Regards,
> Hi Mikhail,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Adding the OpenSSF Scorecards GitHub Action

[Pedro Nacht via internals]

Tyson,

Could you expand on that? It isn't obvious from your comment, and I'm
> curious about this initiative at Google.
>
>
> 1. How many hours a week do you spend working for Google/Alphabet,
> roughly? (e.g., averaged over the last month)
> 2. How many hours a week do you spend working for the Open Source Security
> Foundation, roughly? Is that work part of your job role at Google?
> 3. What is your job title, team, and department in those organizations?
> 4. What is the team size?



[...]



6. Is creating PRs to add this badge part of your job role (If so, the job
> role of which organization)? Is this done in your free time?


>Sorry, it isn't clear - From
> https://opensource.google/documentation/reference/patching, I see that
> the use of @google.com emails is required for all open-source
> contributions, so I was initially confused.


I'm a full-time, run-of-the-mill Software Engineer at Google. Specifically,
I'm a member of the Google Open Source Security Team (GOSST). We don't have
a public-facing website I can point you towards, but you can read this
interview with our tech-lead for some background:
https://reproducible-builds.org/news/2022/04/26/supporter-spotlight-google-open-source-security-team
.

GOSST and the Linux Foundation's Open Source Security Foundation (OpenSSF)
were both created in 2020 after the SolarWinds attack. GOSST is a part of
the commitment Google has made to improve the supply-chain security of the
open-source community (
https://www.cnbc.com/2021/08/25/google-microsoft-plan-to-spend-billions-on-cybersecurity-after-meeting-with-biden.html
).

While most GOSST teams work to develop OpenSSF tooling open-source projects
can adopt to improve their supply-chain security (i.e. Scorecards, AllStar,
SLSA), my team is focused on actually trying to improve the supply-chain
security of external projects (which includes suggesting the Action to
projects where we deem it relevant). So yes, offering to help open-source
projects improve their supply-chain security is my full-time job. We've
been referred to as the "Open Source Maintenance Crew" (
https://therecord.media/google-open-source-security-team-openssf/) and are
currently a team of four (started just a few months ago, still ramping up).


> I also had a few other questions:
>
> 5. How many of the top N security-critical open-source projects does the
> OSSF plan to propose this badge to this year?
> 6. What studies have been published or are being conducted by Google/OSSF
> on the impact of the badge on open-source organizations (or being conducted
> externally, e.g., by universities) (e.g. comparing organizations where it
> is proposed to vs not proposed to)? If so, where can I find them?
>
>E.g., I saw https://news.ycombinator.com/item?id=33309969 recently and
> wanted to learn more about what is known about the impact on metrics of
> projects short-term and long-term. (e.g. on developers that strongly focus
> on scorecards, or perfectionists, or averaged)
>
>I'm interested in learning more about what is being done to ensure the
> overall security, stability, and ongoing improvements of open source
> software in general as an end user, contributor, maintainer, and user of
> the companies that use open source software.
>
>This would be useful to know when an organization considers adopting a
> badge or change to process.
>

I'd first like to emphasize that this isn't about a badge, but including
the Scorecards workflow. A project may choose to include a badge in their
README so that consumers of the project can have a better understanding of
its security posture, but the badge is strictly optional. In fact, the PR I
submitted doesn't include the badge.

As for the impact of the Scorecards system, the timing is quite fortuitous:
Sonatype (also a member of the OpenSSF) released their 8th Annual State of
the Software Supply Chain Report a few days ago (
https://www.sonatype.com/state-of-the-software-supply-chain/introduction).
According to their analysis in the "Project Quality Metrics" section, the
Scorecards system is the best single predictor of a project supply-chain
security. Now, to be clear, that analysis was regarding the Scorecards
results, not whether a project did or did not have the Action installed
(the scores can be calculated by anyone via a CLI tool). So not precisely
what you asked, but I hope this demonstrates the signals the workflow tries
to collect are significant. The report also analyses other tools such as
Libraries.io's SourceRank and a bunch of metrics (public and proprietary).


> 7. Are there recent posts by Google clarifying their involvement in the
> Open Source Security Foundation (funding provided, team size, shared
> employees/contractors, etc)?
>I wanted to know more.
>
>
> https://security.googleblog.com/2022/10/announcing-guac-great-pairing-with-slsa.html
> mentions that the foundation exists,
>but doesn't mention any details about how Google is involved in it.
>
>> 

Re: [PHP-DEV] Proposal to incrementally improve timeout and signal handling

[Levi Morrison via internals]

This kind of thing requires careful thought. My first glance through
it looks good and I definitely want PHP to stop abusing the SIGPROF
signal because it prevents usage by actual profilers, which is
annoying. Full disclosure: I write a profiler for my job.

In addition, I think that there should probably be an internals API
for handing out POSIX realtime signal numbers for platforms which
support it. Quoting from the signal man page:

> Unlike standard signals, real-time signals have no predefined
> meanings: the entire set of real-time signals can be used for
> application-defined purposes.

One could interpret this as meaning we should also make it accessible
to userland, but in line with the one step at a time approach, we can
do that later if we decide we need to. But this is something an
extension can't choose to do by itself: it must be done in core.

I'll review the proposal sometime more carefully. Thanks for bring it up.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Newcomer, PHP pre-processing, Magic Constants __FILE__ and __LINE__ override with #line like in C

[Levi Morrison via internals]

> I think you're also greatly over-estimating how large the startup cost is in 
> practice.  It's real, certainly, but unless you have several nested 
> microservices a well-made framework should have a fairly small overhead.

I want to share my experience that some users have very slow file I/O,
and I regularly see `file_exists` and `stat` show up in slow code
paths. This is one reason I would like to remove the warning on a
failed `include`, because then instead of `if (file_exists($file))
require $file;` or similar, you can just `include $file;` it. When I
brought it up last time, some people actually liked that it has
warnings so... I didn't move forward. Maybe there's room for
`try_include`:

[$included, $retval) = try_include($file);
if ($included) {
// $retval will have the return value of the file
} else {
// $retval will have a warning/error message you can work with
}

I like this quite a bit less than changing `include` to not emit a
warning, but it's not without merits:
 1. `include` still emits a warning, so nobody relying on that will be
surprised.
 2. User gets to control error handling.
 3. Can be polyfilled, it just costs a bit of performance.

Anyway, it's a bit off topic, so I'll stop here.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Adding the OpenSSF Scorecards GitHub Action

[Pedro Nacht via internals]

Hey Jordan,

The tool is only meant to be informative regarding the project's
supply-chain security posture and gives actionable suggestions on how it
can be improved. However, it doesn't create issues, bug maintainers and
volunteers with notifications/emails, or make any assumptions regarding
maintainer/volunteer responsiveness. Maintainers decide when they wish to
check the GitHub Security Dashboard to check the project's security posture.

What actionable benefit could this provide the project?
>

Some of the suggestions it gives for PHP are:

   - add a security policy to the repo where security vulnerabilities can
   be reported privately (the file could simply point users to the
   instructions at https://wiki.php.net/security, for example).
   - set GitHub workflow dependencies to adopt hash-pinning instead of
   major-version pinning. This is to eliminate the risk of tag-hijacking
   attacks where a malicious commit is published to an Action you rely on and
   the tag is then recreated to point to that malicious commit. Dependabot or
   Renovatebot (which the tool also recommends adding to the project) can then
   be used to keep your dependencies up-to-date.
   - set all GitHub workflows with top-level read-only permissions. It
   recognizes that almost all PHP's workflows have top-level read-only
   permissions, but points out that github/workflows/labeler.yml doesn't
   (though it does have job-level contents read-only permissions).
   - and yes, enforce Code-Review and maximal Branch-Protection. I
   understand this would be quite impactful on the project's current workflow,
   but it's the sort of thing that would mitigate the sort of
   attack @ricardoboss mentioned in the linked GH issue. Whether the costs are
   worth the benefit is a question you are all certainly better equipped to
   determine than me.

Some of these tips are one-offs: for example, once you have a security
policy, there's likely nothing else to do in that regard.

However, others offer more continuous monitoring in case there's an
accidental slip-up: if any new workflows are added to the project in the
future without minimal permissions or without pinning dependencies, for
example, the Action will update the Security Dashboard with an alert.

I'd be happy to submit a few PRs to implement the changes I can.

What would forcing maintainers to go through a PR and review process for
> the types of changes that normally get pushed directly to master provide? A
> way for third parties to weigh in? Can't they already do that through the
> mailing list, issues, and PRs?
>

Code review is simply a means of getting an extra pair of eyes on any new
code. Be that to perhaps identify bugs, typos, missed edge-cases or actual
malicious activity as seen last year. It does, however, undoubtedly have
associated costs (crucially, volunteer time). As I stated above, the
cost-benefit analysis is best done by you all who have much more experience
with the project.

Thank you,
Pedro

[PHP-DEV] Microseconds to error log

[Mikhail Galanin via internals]

Description

Hi there,

I started this thread on GitHub but Christoph (cmb69) suggested this
is the better place to discuss such a thing.

(initial post: https://github.com/php/php-src/issues/9745)


Basically, we have quite a high-loaded environment and we really want
to see timestamps
 containing milli-/microseconds in our logs. It is easy to do for our
custom logger
but error messages from the PHP itself narrowed down to seconds (I'm
talking about method php_log_err_with_severity()

Link: 
https://github.com/php/php-src/blob/master/main/main.c#L799:~:text=php_log_err_with_severity

In our repository, we have a hacky patch that adds microsecs in this
log as well.
Unfortunately, such a solution is not really a good approach to
looking into the future.

I wanted to adopt our patch to share it with the community and
potentially merge it into upstream
but stumbled upon the fact that it isn't really straightforward to
format a date/time with microseconds
using the standard API available for an extension.

Basically, I found a couple of options:

(1) We can instantiate a DateTime object and call DateTime::format().
 It looks working but it makes the logging function way more complicated
 and potentially heavy

(2) date_format works directly with timelib_time and can properly
handle microsecs
 but it is hidden inside ext/date/php_date.c, Not really sure if
it's a good idea to make it public

(3) In theory, it is possible to add one more parameter to php_format_date
 but it'll break all the existing code. The change of signature
doesn't look like a good option.
 However, we might be able to introduce another function if we
want to encapsulate work
 with timelib_time within the ext/date.

(4) Derrek Rethans suggested introducing a new function (e.g.
php_format_date_ex) that
 takes care of usecs (see the thread on Github)

Looking into the future, probably we would like to have this format
configurable, if so it looks easy to do but still I
can't see an easy way to handle the microseconds issue.

Could you please help me to find the right way and share your thoughts
about this topic (maybe there are
strong objections against such a change)?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Adding the OpenSSF Scorecards GitHub Action

[Pedro Nacht via internals]

I've made this suggestion as issue #9778 (
https://github.com/php/php-src/issues/9778) and PR # 9789 (
https://github.com/php/php-src/pull/9789), but have been invited by
@damianwadley to bring it to the mailing list.

The Scorecards GitHub Action basically keeps an eye on a repo's security
posture and makes simple, objective suggestions for possible improvements.

For PHP's current Scorecard results, see here:
https://api.securityscorecards.dev/projects/github.com/php/php-src. At the
moment it's a raw json dump, but it contains information on the results of
all the individual checks as well as comments on how to improve the scores.
When the Action is installed, this is cleanly added to the project's GitHub
Security Panel with step-by-step instructions.

@iluuu1994 raised the issue that Scorecards suggests maximal branch
protection and code review (prefer all contributions come via PRs with some
form of code review prior to being added to the repo), which is quite
distinct from the current PHP workflow which allows core maintainers to
simply push directly. The reasons for this are entirely understandable. The
Scorecard simply serves to indicate that other, more secure workflows
exist. Whether their costs (in terms of agility and especially maintainer
time) are worth it is a determination only the core team can make.

I'm happy to answer any questions anyone might have, and am also happy to
help PHP in other ways if I can!

Thanks,
Pedro

P.S. First time contribution to the mailing-list, apologies for any
missteps!

Re: [PHP-DEV] RFC [Discussion]: Randomizer Additions

[Joshua Rüsweg via internals]

Hi


For completeness, it would be good to have nextBool() as well.


I'm just wondering if that's really necessary. Generating a boolean is 
trivial with the nextFloat method (see example 1. Simulate a coinflip 
from the RFC).


No, IMO. Mathematically it doesn't really make sense and talking about 
floats, it will also be a very corner case not reached in tests that 
might happen in production rarely and break things.


Why does it not make mathematical sense? With the nextFloat method, I 
can understand the argument, because that is otherwise opaque, 
especially when you work with probabilities. With the getFloat method, 
however, I can imagine a few cases in which this makes sense. In our 
example, for example, we calculate a random longitude and latitude with 
the method. However, the value of Lat: +90.0 Lng: +180.0 cannot be 
generated, although it is a valid value. However, the value of Lat: 
-90.0 Lng: -180.0 is included. Am I missing something, or is there 
currently no simple mathematical way to implement this with an 
open-right interval?




I am having another small issue.
As the Randomizer class is final, I guess this will not be perfectly 
polyfillable in userland.
So... , if accepted, would it be completely wrong to have these new 
methods in PHP 8.2? What can it break?


I am relatively new and have little to no experience with contributing 
PHP functions, but I don't think this should be done. There is a good 
reason why this is not done and it only causes confusion if any 
functions are introduced after the feature freeze. In the end, however, 
I think it is the release manager who decides.



Cheers

Joshua Rüsweg

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] RFC [Discussion]: Randomizer Additions

[Joshua Rüsweg via internals]

Hi

Tim Düsterhus and I have created an RFC to add new methods that solve 
commonly encountered use cases to \Random\Randomizer. Specifically 
creating a random string consisting of specific bytes and generating 
random floating point values.


You can find the RFC at:

https://wiki.php.net/rfc/randomizer_additions

Proof of concept implementation is in:

* https://github.com/php/php-src/pull/9664
* https://github.com/php/php-src/pull/9679



Some open questions to start the discussion:

* Are you missing other commonly useful operations that are also useful 
to have in core?
* Do you agree with the method names? Within the PR we received comments 
that "alphabet" might not be an appropriate term.
* Shall an option be added to getFloat() that changes the logic to 
select from [$min, $max] (i.e. allowing the maximum to be returned)? And 
how should that look like? Boolean parameter? Enum?




We're looking forward to your feedback.

Cheers

Joshua Rüsweg

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Pre RFC - Additions to the randomizer

[Joshua Rüsweg via internals]

Hi

I would like to introduce a new method for the new Randomizer class [1]. 
I would like to have a function that generates a random string for me 
based on a given alphabet. This function is useful as a building block, 
as many use cases require generating random strings with a specified 
list of characters (e.g. random passwords, voucher codes, numeric 
strings larger than integers) and implementing this in userland requires 
multiple lines of code for what effectively is a very simple operation. 
Furthermore the obvious implementation based on ->getInt() is 
inefficient, as it requires at least one call to the engine per 
character, whereas a 64 Bit engine could generate randomness for 8 
characters at once.


I have opened a Pull-Request on PHP to demonstrate the implementation 
[2] but I am unsure about the method name and decided for 
`getBytesFromAlphabet()` but I am open for better suggestions.


During code review Go Kudo requested that this goes through an RFC and 
Tim Düsterhus requested to handle multiple new methods in bulk. Tim 
implemented a new method, which returns a random float value [3], since 
that's non-trivial to do in userland and an equally useful building 
block like my introduced method.


Since the class into which this function is built is final anyway, the 
methods can be built in with full backwards compatibility.


I look forward to feedback from you!

[1] https://wiki.php.net/rfc/random_extension_improvement
[2] https://github.com/php/php-src/pull/9664
[3] https://github.com/php/php-src/pull/9679

PS: Since this is my first contribution, someone needs to give me karma 
to open an RFC. My account name is `josh`.


Cheers

Joshua Rüsweg

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Concept] Extension methods

[Levi Morrison via internals]

> What are your thoughts?

It's a fantastic feature that I've used in Rust, although there are
some differences. First, it doesn't work for regular methods -- they
have to be part of a trait. Secondly, in general a trait can only be
implemented for a given type if it is in the package which defines
that type, or in the package which defines the trait. Third, the trait
must be in scope. These rules help people understand where the methods
are coming from, which is particularly helpful for large code bases or
teams.

PHP doesn't really have tools for these kinds of restrictions, but I
think it's necessary. You'd need some way to manage where extension
methods are loaded, how they are found, and without pessimizing
performance of method calls in general just because this feature
exists.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Constants in traits

[Levi Morrison via internals]

On Tue, Jul 5, 2022 at 3:39 PM shinji igarashi  wrote:
>
> Hello internals,
>
> I've started the vote for the Constants in Traits RFC:
> https://wiki.php.net/rfc/constants_in_traits
>
> The vote will end on 19. July 2022.
>
> Thanks!
>
> --
> Shinji Igarashi
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

I have changed my vote from No to Yes. I strongly dislike traits as
they are designed and also dislike most of the usages of them I've
encountered in the wild. This strongly dislike is why I originally
voted No, as enhancing a bad thing can make the bad thing get used
more, and that's not what I want. Despite this, I have opted to vote
Yes anyway.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Constants in traits

[Björn Larsson via internals]

Den 2022-07-08 kl. 18:29, skrev Jordan LeDoux:

On Tue, Jul 5, 2022 at 2:39 PM shinji igarashi  wrote:


Hello internals,

I've started the vote for the Constants in Traits RFC:
https://wiki.php.net/rfc/constants_in_traits

The vote will end on 19. July 2022.

Thanks!

--
Shinji Igarashi



I don't have a vote, but I wanted to address this concern about the
"usefulness" of traits, since the *voting* stage is rather the wrong place
to bring up the idea that the existence of the feature itself is a
negative.

In my view, the "correct" way to use traits is for them to be entirely
self-contained. That is, if you can put the trait in *any* class, and have
that trait work as intended *even if* it makes no semantic sense to do so,
then it's a good trait. This is currently somewhat difficult to do in
certain situations. Some of the things the trait may need must live outside
the trait, such as constants. This fact promotes further problematic usage
of the feature.

Requiring something like class constants to be external to the trait
*forces* the kind of trait designs that they have complained about. Voting
"no" because you want to see the feature removed instead is
counter-productive to the process of improving the language itself if the
RFC in question helps correct an oversight of the original feature design
as stated by the original implementer of this feature and helps to promote
more non-problematic usage of the feature.

I don't know how else to view that position except for wanting to keep
design flaws in a feature so that you have additional arguments in the
future to remove it.

Jordan


I think it's quite unlikely to deprecate such a rather big feature and
from that perspective I think one should do it as good as possible.

Even if one thinks that this is a bad feature not to be expanded, why
not try to make it work better? So, I hope this RFC passes!

Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Karma for voting - loophole in the system?

[Jeremiah Johns via internals]

Hi internals,
eleven months ago, there was an interesting thread about a karma for voting on 
RFCs (https://externals.io/message/115464), which resulted in not providing 
this karma to Tobias Nyholm.

But in the latest RFCs  (like 
https://wiki.php.net/rfc/fetch_property_in_const_expressions, 
https://wiki.php.net/rfc/json_encode_indentation or 
https://wiki.php.net/rfc/auto-capture-closure) I can see votes from 
aaronjunker. 
Based what I found here in internals, I think this could be some kind of 
"loophole" in a karma system, because he only created one RFC 
https://wiki.php.net/rfc/global_login which was declined. 

Is it intentional, that getting a karma for creating RFCs allows you to vote on 
all others RFCs? Or is it connected to some other permission Aaron got while 
doing a research for his RFC?

I know that I sound like a snitch here, but I don't think it's good for PHP 
that users without strong experiences (in a userland or/and internal) could tip 
the scales in some RFCs. 

(btw I have no connection to Tobias, I just remember that thread :)

Best,
JeremiahJ

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Levi Morrison via internals]

On Thu, Jun 30, 2022 at 10:48 AM Pierrick Charron  wrote:
>
> Hi all,
>
>
> > - The new CurlUrl class should probably be immutable from the start. It
> > was my biggest mistake not to do that with DateTime.
> >
> >
> After thinking about it and some discussions, I followed Derick's
> recommendation and therefore changed the RFC to make the CurlUrl class
> immutable. All the setters were replaced by new `with*` methods.
> For example setHost is now withHost and will return a new object with the
> host modified. This will prevent confusing behavior where the CurlUrl
> object would be unintentionally modified after being attached to a
> CurlHandle.
>
> Pierrick

It's clear people do not agree on how we should be designing the APIs
for 3rd party extensions. However, let me redraw attention to the
introduction of the RFC:

> One of the goal of this API is to tighten a problematic vulnerable area
> for applications where the URL parser library would believe one thing
> and libcurl another. This could and has sometimes led to security
> problems.

Designing another API on top of what libcurl provides _could make the
problem worse_. I am fine with these kinds of adjustments:

 1. Using exceptions instead of return codes.
 2. Using enums instead of constants if it makes sense (it may not if
they are bitwise-or'd together, which is pretty common for C libs).
 3. Renaming things that have keyword or reserved word conflicts.

I am not fine with designing an immutable, with* style API that
doesn't mirror the underlying library at all. At least, not by itself;
I'd be okay with having both, where the nicer API is built on top of
the lower level, but what is nicer is subjective. As this thread
shows, designing a nicer API will have quite a bit more discussion and
disagreement than "exposing" or "porting" libcurl's API.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3

[Björn Larsson via internals]

Den 2022-06-29 kl. 19:30, skrev Larry Garfield:

On Thu, Jun 9, 2022, at 11:34 AM, Larry Garfield wrote:

Last year, Nuno Maduro and I put together an RFC for combining the
multi-line capabilities of long-closures with the auto-capture
compactness of short-closures.  That RFC didn't fully go to completion
due to concerns over the performance impact, which Nuno and I didn't
have bandwidth to resolve.

Arnaud Le Blanc has now picked up the flag with an improved
implementation that includes benchmarks showing an effectively net-zero
performance impact, aka, good news as it avoids over-capturing.

The RFC has therefore been overhauled accordingly and is now ready for
consideration.

https://wiki.php.net/rfc/auto-capture-closure


The conversation has died down, so we'll be opening the vote for this tomorrow.

Two changes of note since the discussion started:

* The option to mix explicit capture and implicit capture has been removed as 
too confusing/unpredictable.  Either trust the engine to capture the right 
things (the new syntax proposed here) or explicitly list everything (the 
existing syntax we've had since 5.3.)
* We added a section discussing the `use(*)` syntax alternative, and why it 
wasn't, er, used.  (Pun only sort of intended.)

--Larry Garfield


Hi,

Would it be an option to include a "Future scope" with the features:
- Explicit capture that list only the variables to be captured by value 
or reference, nothing else.
- Extending the traditional anonymous function with use(*) for capturing 
everything.


Anyway, hope this passes for PHP 8.2!

Regards //Björn Larsson

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API

[Levi Morrison via internals]

On Tue, Jun 21, 2022 at 10:38 PM Pierrick Charron  wrote:
>
> Hi,
>
> Following our discussions we had on the subject of the new Curl URL API,
> and other curl improvements. I decided to only focus on adding the new Curl
> URL API and put aside all other improvements. Here is the RFC that reflects
> our current conversations.
>
> https://wiki.php.net/rfc/curl-url-api
>
> Feel free to give any feedback, concern or support :-)
>
> Regards,
> Pierrick

IMO, this should mirror the low-level curl url API very directly. The
basis of my opinion is that we do not own libcurl; we are merely
adapting it for use in PHP. We cannot anticipate changes in their
design, nor do we have authority to do so if we feel something should
change. Touching it as little as possible makes it easier to track
upstream changes, etc.

Based on that, I think the naming should be closer to libcurl.:
  - CurlUrl::URL_ENCODE should be CurlUrl::URLENCODE
  - CurlUrl::URL_DECODE should be CurlUrl::URLDECODE

And so on, only differing if necessary because something is a reserved
word. The API should be as exact as possible to what libcurl provides.
The "helpers" getHost, getPassword, etc should be removed and should
expose `curl_url_get` more directly.

Of course, it should be object based instead of resource based, but that's it.

A nicer API can be built on top of it, but I don't think that's the
role this particular API should play.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Under Discussion] Constants in traits

[Stefan Marr via internals]

Hi Nicolas:

> On 22 Jun 2022, at 17:31, Nicolas Grekas  wrote:
> 
> > I'd like to start a discussion on an RFC to allow defining constants in 
> > traits.
> > https://wiki.php.net/rfc/constants_in_traits
> >
> > I'm looking forward to your feedback, including corrections on English 
> > wordings.
> >
> > Thanks!
> >
> > --
> > Shinji Igarashi
> 
> I am initially lukewarm.  One thing not addressed in the RFC that should be: 
> Why were constants left out of traits previously

Hm. This isn’t something that I remember coming up specifically back then.
If it had been discussed in more detail, I’d probably have included it in the 
RFC.
So, my working assumption is: it wasn’t something I really thought about.


> and what has changed to make them make sense to include now?  (I don't 
> recall, honestly, so I have no strong feelings one way or the other yet.)

I am not sure there are reasons to specifically exclude them though.
The RFC, reading over it briefly, and having been away for very long from the 
topic, seems sensible to me.
Taking a very restrictive approach, seems sensible to me, too.

> I'm also wondering why the default value of a const (and a property) could 
> not be changed by the class importing the trait? This sometimes hits me and 
> the original RFC doesn't explain why this is needed.

For constants, I’d lean towards not allowing changes.
If you need to parameterize the trait with a value, having an abstract method 
return it seems a much clearer way of doing it.
Then all parts of the system know “it’s not a constant” and I need to cater for 
different values.

The reason for the strict policies on property conflicts was to keep it simple.
Be conservative, and avoid silent bugs.


Please take everything I say with an extra pinch of salt.
It has been a long time.

Best regards
Stefan

-- 
Stefan Marr
School of Computing, University of Kent
https://stefan-marr.de/research/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Make iterator_to_array() accept all iterables

[Levi Morrison via internals]

On Fri, Jun 17, 2022 at 9:28 AM G. P. B.  wrote:
>
> On Fri, 17 Jun 2022 at 16:20, Tim Düsterhus  wrote:
>
> > Hi Internals
> >
> > I've come across a case where it would've been useful if
> > `iterator_to_array()` would accept iterable instead of Traversable to
> > avoid checking whether the input variable already is an array.
> >
> > To not repeat what I've already written in my proposed PR, please see:
> >
> >https://github.com/php/php-src/pull/8819
> >
> > for more details.
> >
> > In response to my question whether this would require an RFC or whether
> > this is simple enough, cmb pointed to a previous RFC that proposed
> > *adding* a new function `iterable_to_array()` which was declined:
> >
> >https://wiki.php.net/rfc/iterable_to_array-and-iterable_count
> >
> > cmb also suggested that for this reason this topic should at least be
> > shortly discussed on the list, which I intend to do with this email:
> >
> > - Do you believe that my PR requires an RFC / do you want to see an RFC
> > for this?
> > - Would you object to extending 'iterator_to_array' from Traversable to
> > iterable (i.e. to Traversable|array)?
> >
> > Best regards
> > Tim Düsterhus
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
>
>
> Considering the other RFC has been declined, and I can see the value of it
> and the change is rather minimal, if no one has any objections I think this
> is fine to land without any RFC.

Personally, I take the opposite view. This has already been declined;
why should it be able to avoid the RFC process when something so
similar was declined recently?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3

[Björn Larsson via internals]

Den 2022-06-13 kl. 14:57, skrev Arnaud Le Blanc:

On samedi 11 juin 2022 23:14:28 CEST Rowan Tommins wrote:

My main concern is summed up accidentally by your choice of subject line
for this thread: is the proposal to add *short closure syntax* or is it
to add *auto-capturing closures*?


The proposal is to extend the Arrow Functions syntax so that it allows
multiple statements. I wanted to give a name to the RFC, so that we could
refer to the feature by that name instead of the longer "auto-capture multi-
statement closures". But the auto-capture behavior is an important aspect we
want to inherit from Arrow Functions.


As such, I think we need additional features to opt
back out of capturing, and explicitly mark function- or block-scoped
variables.


Currently the `use()` syntax co-exists with auto-capture, but we could change
it so that an explicit `use()` list disables auto-capture instead:

```php
fn () use ($a) { } // Would capture $a and disable auto-capture
fn () use () { }   // Would capture nothing and disable auto-capture
```
I like this idea very much. In the RFC two variables are captured

explicitly and one implicitly.
$c = 1;
fn () use ($a, &$b) { return $a + $b + $c; }

I don't see the UC / value for not specifying $c while specifying
$a. Think it's much clearer when capturing variables to implicitly
capture everything or list the ones that should be captured. One
only need to think about which variables are listed, not the ones
that might be implicitly captured.

Of course capturing by reference will always be required to list
and if combined with capturing variables by value, they also needs
to be listed.

The there is this other proposal to enhance traditional anonymous
functions by allowing the syntax use(*), meaning capture everything.
Even if it's outside the scope of this RFC it could be mentioned in
"What about Anonymous Functions?" or "Future scope".

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Early feedback on encrypted session PR

[Eric Mann via internals]

I'm not sure I'm a fan of the PR as it stands, but the idea of 
encrypting session data - definitely.


When sessions are stored on disk, that data is plainly visible by anyone 
(or any process) with read access to that disk. If they're cached 
instead in a DB or an in-memory system like Memcached, the same rules 
apply - anyone else who can read data from that system can read what's 
stored in the session. That being said, how much you care about this 
level of access depends very much on your threat model. If sessions are 
storing data like upvotes or view counts, this information likely isn't 
sensitive enough to worry about whether or not things are encrypted.


If you're storing customer PII in a session, though, then protecting 
this data "at rest" in your session store becomes critical.



It is already possible to write an own SessionHandler which
encrypts/decrypts the session payload.  That said, I'm not against
adding an encryption option.


This is 100% the route I've taken in the past. 
https://github.com/ericmann/sessionz (which I admit needs some updates) 
includes one example SessionHandler implementation that does just that. 
However, it would be fantastic to see this as part of the standard 
library. Session management in PHP can be tricky, particularly in larger 
applications with multiple entry/return points. A standard (read: 
simplified) implementation would go a long way.


--
Security Principles for PHP Applications 


*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA 
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com 
ttmm.io 
Twitter icon  LinkedIn icon 

Re: [PHP-DEV] Re: [8.2] Release Manager Election

[Evan Sims via internals]

Congratulations Sergei and Pierrick!

Cheers,
Evan

On May 18, 2022, Ben Ramsey  wrote:
> > On May 11, 2022, at 09:51, Ben Ramsey  wrote:
> > 
> > Happy middle of the week, everyone!
> > 
> > We’ve had another great turn-out for PHP Release Manager selection
> this year.
> > 
> > In the role of “Veteran” release manager, Ben Ramsey[0] (that’s me!)
> has volunteered to mentor two rookies, so there will be two seats up
> for grabs. As I mentioned in an earlier message, Joe and I discussed
> that it might be a good practice to have one of the rookie RMs from
> the current release serve as the veteran for the next release. In this
> way, any new advances or changes to the process will be carried
> forward to the “next generation” much more smoothly. So, we’re going
> to give that a try and see how well it works.
> > 
> > For those two rookie seats, we’ve got seven eager candidates for
> your consideration [1-7]. Some of these included a statement about
> their background in their initial email volunteering for the role, the
> rest I encourage to reply to this thread providing some background on
> why they’ll be awesome.
> > 
> > Voting is now open on https://wiki.php.net/todo/php82 using “Single
> Transferrable Vote” (STV). Those who participated in prior elections
> will recognize the format; for the rest, the TL;DR is that it allows
> each voter to state their preference order by voting multiple times.
> There are seven polls on the wiki for your seven preferences, in
> descending order. Using some math that I’ll leave to Wikipedia[8] to
> explain, we’ll start with the 1st preference and gradually remove
> candidates with the fewest votes, transferring votes that had
> previously gone to them to their voter’s 2nd preference, and so on.
> Once two candidates have a quorum (Droop quota), those will be
> officially selected as our RMs. Derick Rethans has volunteered to
> proctor the tabulation of the votes since he still has scripts from
> last year.
> > 
> > As you consider each candidate, please bear in mind that this is a
> 3.5 year commitment and is a position of trust.
> > 
> > Thank you in advance for your consideration.
> > 
> > Your 8.1 Release Managers,
> > Ben Ramsey, Patrick Allaert, & Joe Watkins
> > 
> > Vote Opens: 11 May 2022
> > Vote Closes: 18 May 2022
> > 
> > Refs:
> > 0 - Ben Ramsey: https://news-web.php.net/php.internals/117664
> > 1 - Sergey Panteleev: https://news-web.php.net/php.internals/117596
> > 2 - Evan Sims: https://news-web.php.net/php.internals/117621
> > 3 - Aaron Junker: https://news-web.php.net/php.internals/117623
> > 4 - Calvin Buckley: https://news-web.php.net/php.internals/117627
> > 5 - Eric Mann: https://news-web.php.net/php.internals/117629
> > 6 - Pierrick Charron: https://news-web.php.net/php.internals/117650
> > 7 - Saif Eddin Gmati: https://news-web.php.net/php.internals/117702
> > 8 - https://en.wikipedia.org/wiki/Single_transferable_vote
> > 
>
> The polls have closed, and Derick’s scripts have tallied the
> votes.[^1]
>
> Our 8.2 “rookie” release managers are:
>
> * Sergey Panteleev
> * Pierrick Charron
>
> Congratulations!
>
> Thank you to all the candidates! I hope you’ll consider putting in
> your name for future release manager elections, and as always, PHP
> needs your help in many other ways, so please continue to volunteer
> and help out.
>
> Sergey and Pierrick, I’ll be in touch with you soon to get you started
> on the first alpha release of 8.2, due out on 9 June.
>
> Cheers,
> Ben
>
>
> [^1]: https://gist.github.com/derickr/f13396ce8d9c0ed7bc84a23ba15d5406