Re: [PHP-DEV] [RFC] [Vote] Deprecate GET/POST sessions
Hi All, The voting has ended. RFC was accepted unanimously with 29 votes. Regards, Kamil
Re: [PHP-DEV] [RFC][Discussion] PDO driver specific parsers
I think the question here was more about what the syntax will be after the parameters are substituted. But if I recall correctly, the quoting is done by PDO:: quote so the syntax will remain the same. Only the buggy behavior would be fixed when it comes to recognizing parameters.
[PHP-DEV] [RFC] [Vote] Deprecate GET/POST sessions
Hi Internals, I have opened the vote on https://wiki.php.net/rfc/deprecate-get-post-sessions It will close on 2024-04-23 Regards, Kamil
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
>1. In session_start(), it is possible to override ini settings like that:
>
>```php
>session_start([ 'use_cookies' => '1', 'use_only_cookies' => '1',
>'referer_check' => '' ]);
>```
>
>The relevant options should also be deprecated in that context.
Yes, they are. You can see that in my draft PR
https://github.com/php/php-src/pull/13578
> 2. A clarification: Suppose that I have `session.use_only_cookie = 1` in my
> ini file (no deprecation warning), and I call
> `ini_set("session.use_only_cookie", "1")` in my code (no-op). Will the
> `ini_set(...)` invocation trigger a deprecation warning?
As mentioned in the RFC, only changing the option to the deprecated
value triggers the deprecation. You can verify this using my draft PR.
Similarly, if your INI file triggers a deprecations due to for example
session.use_only_cookie=0 and then in your PHP file you change it
using ini_set("session.use_only_cookie", "1") or using the argument to
session_start(), it will only trigger the deprecation during startup
and not during runtime of the script.
Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions
Hi Pablo, Interesting proposal, but immediately I have two questions: 1. Why is passing extra arguments a problem at all? Is generating a warning a good idea? If you would like to introduce a new syntax to enforce non-variadic functions, shouldn't it be a runtime error then? Generating a warning makes it look like the new syntax still allows for variadic arguments, but passing the extra arguments now is somehow a bad thing to do. 2. How does this affect func_get_args()? Will the function stop working or continue working as before? Regards, Kamil
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
If there are no more comments, I would like to put this RFC to vote in the next two days.
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
Hi Everyone, Upon consideration of your comments, I have decided to adjust my RFC. Please see the updated version https://wiki.php.net/rfc/deprecate-get-post-sessions Changes include: - session.use_cookies will not be deprecated - session.trans_sid_tags, session.trans_sid_hosts, session.referer_check will get deprecated too (although I am not sure how to implement the deprecation message yet) - the SID constant will also be deprecated as part of this RFC - mentioned that output_add_rewrite_var() will remain unaffected Regards, Kamil
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
-- Forwarded message - From: Anton Smirnov Date: Sun, 3 Mar 2024 at 19:56 Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions To: Kamil Tekiela Greetings! I'm sorry for addressing you directly, if you can forward this message to internals I'd be grateful. It seems outlook is still banned and I can't re-subscribe with any other email (tried outlook, gmail, vivaldi and a small private service) On 02/03/2024 23:10, Kamil Tekiela wrote: > Hi Internals, > > I would like to start a discussion on a new RFC > https://wiki.php.net/rfc/deprecate-get-post-sessions > > Please let me know whether the idea is clear and the RFC is understandable. > > In particular, I am looking for any feedback as to why this is a bad > idea. The primary motivation behind this RFC is to reduce potential > security pitfalls. > > Regards, > Kamil Tekiela Greetings! As I know some session-related middlewares force custom-only session_id handling by setting use_cookies = Off use_only_cookies = On and then using session_id(...) directly Example: https://github.com/middlewares/php-session/blob/master/src/PhpSession.php#L137 I think if you're making this hack impossible, you should provide an alternative non-hackish way to do this. Maybe just keep use_cookies = Off A wild idea: 1) Add a temporary config # by default; current behavior; # throws a deprecation right from the introduction cookies.use_post_get = On # do not set the session from POST and GET cookies.use_post_get = Off Remove it in 9 with the rest 2) keep use_cookies in PHP 9 with the updated meaning I don't think it's a good solution but maybe it can spark a better one Best, Anton
Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
Hi Anton, > As I know some session-related middlewares force custom-only session_id > handling by setting > >use_cookies = Off >use_only_cookies = On > > and then using session_id(...) directly > > Example: > https://github.com/middlewares/php-session/blob/master/src/PhpSession.php#L137 I was not aware that some frameworks do that. But I don't understand how this works. IMHO if you disable the use of cookies, but you also tell PHP to use only cookies it creates an impossible scenario. Isn't that right? The way I understand it is that there are 2 ways of propagating session ID: cookies and GET/POST. You can tell PHP to use both or either one of them, but not neither. Only cookies: use_only_cookies = On use_cookies = On Only GET/POST: use_only_cookies = Off use_cookies = Off Both: use_only_cookies = Off use_cookies = On The remaining 4th combination should create an impossible scenario. Does it mean to use neither option? I can change the proposal to deprecate only use_only_cookies=Off and session.use_trans_sid=On and leave session.use_cookies alone, but I just can't think of a situation when leaving that setting in PHP would make sense. I am probably missing something very important and I would appreciate it if someone could explain to me what it is. I wouldn't want to deprecate something that is used in popular frameworks.
[PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions
Hi Internals, I would like to start a discussion on a new RFC https://wiki.php.net/rfc/deprecate-get-post-sessions Please let me know whether the idea is clear and the RFC is understandable. In particular, I am looking for any feedback as to why this is a bad idea. The primary motivation behind this RFC is to reduce potential security pitfalls. Regards, Kamil Tekiela
Re: [RFC] OOP API for cURL extension
I love it! When is CurlMultiException and CurlShareException thrown? I feel like this part in general is not very clear in the RFC.
Re: [PHP-DEV] [Proposal] Add `savepoint()` method to PDO
Hi Saki, Why does this have to be done in PHP? Why can this not be done in SQL? Also, I am not sure that mysqli implements this properly. It's probably not the best extension to take an example of. Regards, Kamil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Add http_(get|clear)_last_response_headers() function RFC
Sorry, my bad. I thought the vote started 2 weeks ago. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Add http_(get|clear)_last_response_headers() function RFC
I think it might be even better to extend it by 2 weeks. It looks like people were unaware that the voting has started on this RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
FWIW I think one year is more than enough of deprecation time for any change, especially for something so easy as this. It's not like we are forcing users to upgrade to the newest version as soon as possible. I still haven't used PHP 8.3, and I most likely will not use it for another year. In practice, a year of deprecation time is much more for most of the people. Additionally, people can start fixing it right now. The tools already provide such an option and the alternative syntax has been in existence for some time. If we find out that the change is being more difficult to implement than anticipated, the solution would be to postpone the removal. Deprecation can happen in any version and I see no reason to restrict this by implementing a new policy. But if anyone would want to do this, then there should be a separate RFC and discussion for this. In terms of this RFC, I see no reason not to accept it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
I fully support this. I even wanted to propose this RFC myself. Implicitly nullable parameters are extremely confusing in PHP 8 and they are very easy to replace.
Re: [PHP-DEV] [RFC] Add dedicated StreamBucket object
What should users replace $bucket property with in PHP 8.4? Is there an alternative or is this a deprecation without a way to solve it? If there is currently no alternative I would not deprecate it. Just remove it once it becomes useless. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Final-by-default anonymous classes
I have voted no. Not because I disagree with the proposal, but because I think the timeline is wrong. First, we should identify a way to deprecate and disable the option of naming anonymous classes. I suggest we deprecate this "feature" in PHP 8.4 and remove it in PHP 9.0, as well as making the anonymous classes final. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Vote] Resource to object conversion
Hi Máté, I have one question. If the primary stream resources get the is_resource hack, what hampers the changes from landing in a minor version? I'd assume that the migration would be mostly seamless. Is it the get_resource_type checks? Is it because is_resource also checks whether the resource is closed? Regards, Kamil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Declaring new elements as references while destructuring within a foreach() head
I don't know if this was designed this way purposefully, but it makes
sense to me. I see nothing out of the ordinary here. It makes for some
really nasty code, but that can probably be said about all code that
uses references.
If we try to simplify your example, we can see more clearly what's
happening. First, let's take the loop out of the equation.
$arr = [];
['foo' => &$v] = $arr;
$v = 1;
var_dump($arr);
This creates an array with one element whose value is 1 and key is
foo. That array restructuring is pretty much just a syntactic sugar
for an assignment operation. So we can simplify this example further
by replacing the array destructuring with this:
$v = & $arr['foo'];
Now, this looks like an average assignment of reference in PHP. The
rules of assignment-by-ref state:
> If you assign, pass, or return an undefined variable by reference, it will
> get created.
https://www.php.net/manual/en/language.references.whatdo.php#language.references.whatdo.assign
Since array elements have similar logic to plain variables, this
applies to undefined keys, too. The foo key in the example above is
created initially with a NULL value. Using the variable alias we
created, we can assign a different value to it.
Coming back to your example from SO, the array destructuring in
foreach is just a convoluted way of assignment-by-ref. After
simplifying it, it becomes:
foreach ($array as $key => $row) {
$x = & $array[$key]['new'];
$x = $row['bar'];
}
Which looks pretty normal to me. I would say it's definitely not a
bug. It's just a mix of two PHP features that together make up for
some confusing-looking code.
--
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 ?
> Convert your PHP source files to UTF-8. If the solution is as easy as just converting the encoding of the source file, then why did we even need to have this setting at all? Why did PHP parser support encodings that demanded the introduction of this declare? -- 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 ?
Hi Hans, Can you share a little more details about how this works? This is a pretty niche functionality, so most people probably don't know what it is, how it works, or why it should no longer be used. Also, as Claude mentioned, what is the preferred alternative? Regards, Kamil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC Proposal - static modifier for classes
A class with a private constructor can still be instantiated. A class that cannot be instantiated is pretty much useless. A static class would be just a collection of functions. And I know that many developers write such classes but it doesn't mean the language should encourage it. After all, if someone wants to create such a "collection of functions" they can already do that and they don't need a static class. By definition a class is a template for creation of objects. Everything in PHP OOP is designed with this in mind. Adding static classes would be a severe complication in the language syntax that goes against the OOP principles. That's like saying that some people use a saw to hammer in nails and we should designs saws that make it easier. There are so many unanswered questions in this proposals without even considering things that might be implemented in the future. Such an addition would be a major change that could have unforseen results. And by the way, you are not going to win anyone's approval by being rude and condescending.
Re: [PHP-DEV] Passing null to parameter
You must enable bleeding edge.
Re: [PHP-DEV] Passing null to parameter
Hi Craig,
Don't get me wrong, but I have a feeling you still didn't understand fully
my first message.
That's what I thought, but for some reason, casting null is deprecated only
> when it's provided as an argument to functions, all other cases it's
> fine... weird right?
>
No, passing null to non-nullable parameters is already an error. It has
been for a long while now. The only exception are some built-in functions
that silently ignored that and cast the value to another type.
> > Instead, if you want, submit a proposal to reverse the direction.
>
> No point, people will vote against, and will just entrench their position
> (people like to think they are right, this would involve them changing
> their mind; and because everyone voting is almost certainly using
> strict_types=1, it won't affect them, and they will see it as a way of
> pushing "lesser developers" to using strict types).
>
I don't use strict types and I am pretty sure there are many more people
that don't. I started using them more recently but I don't use them
everywhere yet. However this discussion doesn't have much to do with strict
types.
> Such a change could also be complicated to implement given how ambiguous
> it would be.
>
> It always worked that way (for internal functions) - for arguments that
> accept a string, cast null to an empty string; if it accepts an integer
> then it's 0, etc.
>
It only worked like that for some built-in functions. That's because
built-in functions didn't (and some still don't) respect the PHP type
system. However, passing null to non-nullable param was never allowed.
> So unless it's causing some serious problems for PHP developers or users,
> I think it's too late to change the design of the language.
>
> At the moment it's causing deprecation log entries (which are ignored),
> but the problems are everywhere, like the following (Laravel), is this
> really that unreasonable?
>
> ```
> $a = trim($request->input('a'));
> ```
>
> This will start getting Fatal Type Errors in 9.0... and finding these
> "mistakes" is close to impossible (phpstan doesn't find them; psalm
> requires high levels 1-3).
>
It's only throwing a deprecation because we started to fix the built-in
functions so they behave like the rest of the language. That's a bug fix,
but as I explained earlier it was always an error. That's how the language
was designed.
Finding it is difficult, I agree, but that's the whole purpose of the
deprecation. It's supposed to help you find all the mistakes. The mistakes
are only with built-in functions, so the scope is very limited. With all
other functions the error is caught during development because of the
error.
Casting null to other types is not a mistake, but passing null to functions
that don't expect it, is a mistake. There's no defined behavior in PHP as
to what should happen. Allowing passing null to non-nullable parameters is
a big feature request that never was part of PHP. It's not something that
was removed, it's something that never existed. Just think about a simple
example and how ambiguous it would be.
function abc(string|int $p) {}
abc(null);
What should null be converted into and why? If you as a developer know then
you can cast the argument to an appropriate type but on the language level,
it's not really possible.
So, in conclusion, we are not supporting you because we are stubborn or
that we want to force strict types, but because resolving this problem in a
way you want is extremely difficult and borderline impossible.
Regards,
Kamil
>
Re: [PHP-DEV] Re: Passing null to parameter
I don't think that would actually be wise. Automatic casting of null to other types is a handy feature and deprecating it brings no benefit to anyone. Instead, if you want, submit a proposal to reverse the direction. Make it so that null is cast to an appropriate type in params and return values. This should only apply in loose-type mode and it would make nullable types useless. Such a change could also be complicated to implement given how ambiguous it would be. But if you can outline tangible benefits and write a PR to show how it would work, I think the community would review the RFC. But as I expressed before, the current path seems to be the most logical. Despite the decision to introduce nullable types in PHP 7, which as you pointed out creates an incompatibility with all other type juggling rules, this is the cleanest and least ambiguous solution. As for the negative responses, it's probably because it's been many PHP versions since the nullable types were introduced. People accepted it and are generally satisfied with how it works. Only after the last bit was decided to be fixed in PHP 9.0, you started a discussion pointing out that on paper it's misaligned with other parts of the language. Just because null is converted to string in one context and throws an error in another is not necessarily a bad thing. So unless it's causing some serious problems for PHP developers or users, I think it's too late to change the design of the language. Regards, Kamil
Re: [PHP-DEV] New RFC : empty() function
Hi Alessandro, I would still advise to just let this empty() construct die a natural death. If you want to change anything, you must remember that it's basically a syntactic sugar for `@!$var` For example if(empty($var)) is just if(@!$var) To change this function would require changing the rules for type juggling.
Re: [PHP-DEV] New RFC : empty() function
I would be voting against any function that checks for "empty". The `empty()` construct we have now should almost never be used in any reasonable code. It should be avoided at all cost. For this reason, I see no need to introduce a new variant of the same thing. I also don't believe there is any need to fix or change the existing construct. Leave it as it is for use in legacy projects. Maybe in a distant future we will be able to deprecate it or maybe we won't. While I personally consider it a menace, I don't mind it existing in the language. But please do not add any similar functionality. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
Hi, I don't understand what you are proposing and what problem you are trying to fix. The RFC is not explaining things well.
Re: [PHP-DEV] Passing null to parameter
A code like this already throws a fatal error.
function enc(string $a){}
enc(null);
The only thing remaining to be fixed in PHP 9 is to make this error
consistent on all function invocations.
> I didn't realise the payment gateway doesn't always provide the order
reference
Well, there you go. This deprecation message actually informed you of
something. Without it, you would never know that you have a logical
error in your code. It works as intended.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Expose pdo_parse_params to userspace
Hi, I have to say I am not a fan of this proposal. While definitely a super nice feature in PDO, it's more of a hack rather than proper feature. Certain RDBMSs support named parameters in prepared statements, but MySQL doesn't. Therefore, the solution implemented in PDO is a hack. It's very flawed and the current implementation has multiple bugs and shortcomings. One could say that some bugs are security issues. For the above reason, I don't think we should support this in mysqli. We cannot reliably implement such feature. We could make a copy of pdo_parse_params and fix as many MySQL issues as possible, but we would never be able to fix it fully due to the nature of MySQL API. If someone wants to implement this in userland, then be my guest. As long as you are aware of the shortcomings and you know how to use it safely then it's fine. Unrelated, but I would not consider the async feature of mysqli useful or even a good reason to abandon PDO. IMHO the async feature is a failed experiment with limited applicability. Regards, Kamil Tekiela
Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost
Yes, BCrypt uses only the first 72 bytes for hash generation. You can
test it with:
var_dump(password_verify(str_repeat('a', 72).'sdfsdf',
password_hash(str_repeat('a', 80), PASSWORD_BCRYPT)));
But I would not consider this an issue. Users rarely create passwords
longer than 72 bytes. 72 bytes is still a very long password and not
easily guessable. What's more important is to have the minimum limit
check. But why bother checking the 72 maximum if the algorithm won't
complain about longer input? It doesn't impact security in any way.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]
>Do you think there is still demand for such error mode control features? > >Personally, I've never seen anyone prefer silent mode, so I think it's worth >making the drastic change. This may be right. There isn't a demand for this in **new** code and I doubt anyone would come forward with a reason to use silent mode now. However the purpose of keeping this mode is to enable old legacy code to run without major refactoring. This is the practice coming from the days before PHP 5 when using exceptions wasn't common. Plenty of applications are still running code designed 20 years ago because PHP keeps as much backward compatibility as possible. The code would benefit from modernization, but this would require a lot of effort from its maintainers. We may get away with deprecating and removing PDO silent/warning mode because it's an extension that was introduced in PHP 5 and everyone was on board with using exception mode. We probably cannot remove silent mode for other extensions that either mimic older extensions that didn't use exceptions (e.g. mysqli) or have been introduced before PHP 5. The reason is that people designed their code using silent mode and removing it now would cause some serious headaches. Another point to consider is that PDO had silent mode as default for a long time. You may be surprised, but many people weren't aware that it can throw exceptions. My guess is that's a very small proportion of all projects though. With PHP 8.0, they just slapped one line of code and called it a day. Having said that, I think removing PDO's silent mode is possible soon, even in PHP 9.0, but we may anger some people. All warning modes can be deprecated in PHP 8.4 and removed in PHP 9.0. Silent mode of other extensions should be carefully reviewed one by one. Deprecation in PHP 9.0 and removal in PHP 10.0 might be a better option. Regards, Kamil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Adding new error to mysql_stmt_data_seek
Hi Internals, This is in relation to PR #10419: https://github.com/php/php-src/pull/10419 I was hoping to get it merged into PHP 8.3, but there were some objections. I would like to receive some opinions from the broader community. According to the MySQL standard mysql_stmt_data_seek should be a void function [1], but in mysqlnd it was always returning a bool; it returns false when used in invalid context. Since we no longer support libmysql, we are no longer restricted to not knowing if this action failed. Checking for an error condition and informing the mysqli user about incorrect usage makes sense. The only time this function returns false is if it's used on PS without a buffered result set, hence the text of the error message. It is always a developer error due to invalid use of this function. Letting the developer know they used the function incorrectly would be a welcomed addition, in my opinion. What do you think? [1]: https://dev.mysql.com/doc/c-api/8.1/en/mysql-stmt-data-seek.html Regards, Kamil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Update icon after 20 years
Can we align it to be the same as https://www.php.net/favicon.ico?v=2 ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Possible RFC: PDOStatement::addBatch
Hi Vinicius, What would be the reason to add this? A reason cannot just be that there is no such function. You can easily do it with a loop like you have just shown. There isn't really any other way unless we introduce some driver specific SQL builder. So what would we gain from it? Is it speed, security, efficiency? String concatenation isn't an alternative though. Regards, Kamil
Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
I am not sure if others agree but in my opinion, Global Mersenne Twister should have been a separate RFC. It has a discussion point that people might want to discuss on mailing list first.
Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures
Hi Máté, I agree with this proposal, and I will be voting yes. The function overloads are not a big issue for PHP developers, and some are very much in use, but the reasons you listed are convincing and the manner in which you propose to do it should create an easy upgrade path. I think one year of deprecation is not enough. I believe the functions that get replacements should be deprecated immediately in PHP 8.3 to give people two years of deprecation notice. It doesn't make sense to me to add a replacement but not deprecate the old variant. `($rm = new ReflectionMethod(explode(“::”, $string));) ` I think you forgot a splat operator here. ReflectionProperty::setValue could have an alternative called ReflectionProperty::setStaticValue. Then there would be no need for the unused parameter anymore. The overload of array_keys should be replaced with a new function array_search_all. This overload is little known and very confusing. The overload of ldap_exop should just be deprecated. An alternative already exists and is the preferred way. I wasn't aware that pg_execute has an overload apart from the default connection one. Could you explain what that overload is? stream_context_set_option should get alternative stream_context_set_option_array. What is the last item in Future scope supposed to be, because I think ReflectionProperty is a typo. Why is implode() not mentioned in this RFC? Regards, Kamil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Moving PHP internals to GitHub
I love this idea. Although GitHub is not perfect, it would be so much better than a mailing list. Mailings lists are annoying: they have very poor searching capabilities, you can't unsubscribe from a thread you are not interested in, you can't follow the conversation easily because it's not always obvious what is a quote and what is not, there is this annoying rule about bottom posting that makes messages more difficult to read, there is no code formatting, no editing, no tagging or organizing of message in any way, and a lot more smaller annoyances. It's the same as SMS or any other simple chat application. It's just too limited. But unfortunately, if it came to a vote, I would vote NO. The mailing list must remain IMHO. It's terrible and annoying but it's also very simple and ubiquitous. And that's what is needed for inclusivity. A lot of senior developers prefer this kind of communication method so if we asked them to switch over we could lose them. Not to mention people who have no access to GitHub because of sanctions. It's the ubiquitousness of email that makes it the best tool for the job even if it's actually terrible for technical discussions.
Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading
> > We have the special constants like \MyNamespace\MyClass::class. Would > you envisage (or is there value in) equivalent constants like > \MyNamespace\MyFunction::function? > If anything, I would suggest renaming the existing constant to something more meaningful. There is no point in adding ::function because that would just be an additional confusing alias for the same thing. Doing strpos::class works just fine, but is semantically incorrect.
Re: [PHP-DEV] Future stability of PHP?
On Mon, Apr 10, 2023, 04:17 Deleu wrote: > > Or maybe when you wrote "Even if nothing would change in PHP 8" you meant > something different than what I interpreted? > I meant things like refactoring, fixing bugs, updating dependencies. Changes in code unrelated to changes in the language. When people leave technical debt for later, the upgrade becomes more painful to them. >
Re: [PHP-DEV] Future stability of PHP?
> But what's the point of starting a greenfield project in PHP while Typescript is right there? If that is true then we have pushed PHP to its death. PHP is dead and we can move on to other projects. But that's obviously not true. I could claim the complete opposite: why start a project in Typescript when PHP is there and it's a more mature language? At the end of the day, it comes down to personal preference. The language is perfectly suitable for greenfield implementation. If it wasn't, then there would be RFCs trying to change things that are wrong with it. > But the cost is catastrophic. If you have a legacy codebase hanging over your head you probably know how hard it is to upgrade it. I wonder about this every time I hear this claim. What exactly changed in PHP 8.0 that made the upgrade path so difficult? The upgrade to PHP 9 may be a little more difficult because of some of the recent deprecations, but that's still years ahead of us. So what's exactly driving people away from PHP 8? Why is the adoption dwindling? I'd rather say that the roadblocks people are facing in upgrading legacy projects are not specific to PHP 8, but rather a technical debt acquired over the past 10-15 years. Even if nothing would change in PHP 8, people would still complain about the upgrade because of unrelated reasons. But please prove me wrong. Is there actually any change in PHP 8.0 that is a major source of work? If PHP went in the wrong direction, let's suggest something to fix it. If there are no suggestions for improvement then what are people complaining about? Regards, Kamil
Re: [PHP-DEV] Future stability of PHP?
Hi Stephan, Generally, PHP tries to keep as much backwards compatibility as possible. Breaking changes are limited to minimum and done in the least obstructive way possible. When a deprecation is introduced, you have at least 3 years to update your code. But PHP also tries to move forward and the language improves each year. We certainly got many more features than breaking changes. Just think of match expression, enums, attributes, constructor property promotion, new Random API, readonly properties/classes, first-class callable, consistent errors and many more. The biggest improvement in PHP 7 and 8 was a comprehensive type system. It's something that you don't have to use, therefore doesn't affect existing code much, but makes development so much more enjoyable and less bug-prone. I know I have discovered many bugs because of migration to PHP 8 and introduction of proper types. And this is the direction PHP is going in. The language is still dynamic and allows for taking the easy route, but new features focus on reducing bugs by making the code's behaviour less surprising. If you try to adhere to clean code principles, upgrades should not be a huge problem. Use static analysis and good tests. Learn and follow clean code practices, e.g. SOLID. Use abstraction in your code; it's better to change code only in one place than change it across hundreds of files. Some tools help you during migrations, such as Rector and phpcbf, but to use them proficiently, your code needs to be free from surprises. Dynamic properties are a very good example of surprising behaviour. By looking at the definition of the class, you don't know what properties it has. If any of the methods use undefined properties, both you and static analysers will be surprised by this. There are certain things you should avoid in your code like fire. Not because they might be removed from the language, but because they make your code unclean and cause bugs. Here is my list: - Arrays. Yes, they are a major feature of the language but also a major pain in the... Use proper data structures, which may use arrays internally, but don't use bare arrays in your code. Value objects and DTOs are invaluable. - Isset and empty. They are sometimes necessary and sometimes they are the easiest choice, but they hide so many bugs. Every time you use any of them, it should raise an immediate red flag. - References. I don't understand why the language still has this feature. Hack got rid of it and that was a very smart decision. You don't need references. Use them almost never. - Globals and superglobals. This should not need explaining. Pretty much in every language, these are pure evil. They make changes to the code an experience similar to disarming a bomb. It's tempting to use $_GET, $_POST, $_REQUEST anywhere in your code, but if you want to avoid bugs and surprises, you'd better stay away from it. There should probably be at most one place in every project where these are used. - extract() and compact(), and variable variables. These should only be used in a very tightly controlled scope, and even then, their usage can be contested. Ideally, variable variables should not exist in the language; we have arrays after all. - Sanitizing filters. Sanitization is too ambiguous term to be useful. What you should be using is validation and formatting. Validate your inputs to make sure they are the type/value you expect. Format the output so that it can't break the context it is in. - Loose comparison. I have liked that about PHP in the past, but in recent years I became a strong supporter of strict comparison. Why? Because "0" == false. Forbid using loose comparison in your coding standard and forget that it exists. Don't let the language make a fool out of you. You are the developer and you know what type you expect. Following these guidelines will not only help you avoid bugs in your code but also will make the upgrade process much less cumbersome. This and adhering to the strictest level of the static analysis tool of your choice is the recipe for success. Try to stay up to date with the changes. Every year when PHP releases a new version, go over the changelog and make an effort to learn and use new features. Even if your production is 3 years behind, you can try these out in your development environment. PHP will move forward and add new features, but sometimes it must also break some things to move forward. Kind Regards, Kamil Tekiela
Re: [PHP-DEV] [RFC] Define proper semantics for range() function
> > I've changed the behaviour to throw a ValueError if a negative step is > provided with increasing range and accept negative steps for decreasing > ranges. > I am not sure this is better. This would introduce a BC break because now it's not as easy to avoid the error as you can't just wrap the variable in abs() call. I am not sure why we are even treating this as an error. It looks to me like PHP already copes with this whether it's a positive or negative number. If we just want to inform the user that the sign has no meaning, we can raise a Notice and leave it at that. It's not wrong that the step is negative, it's just a pointless sign.
Re: [PHP-DEV] Two Issues regarding Named Parameters; want to understand the technicality
Hi Hamza, If you encounter a bug, please create a GitHub issue with reproducible steps. Your description of a program crashing is not actionable, as we cannot reproduce this error. Regarding your second point, how do you want this to work? $names is just a collection of string parameters. It's not a single parameter so you cannot refer to it by name. When you use named parameters with variadic parameters, then the names you specified will be used as array keys. So no error there, and no warning should be raised. But I don't know what you had in mind of how this is supposed to work. Regards, Kamil
Re: [PHP-DEV] How to deal with bugs in vendored libraries?
Hi Max, On Thu, 9 Feb 2023 at 16:05, Max Kellermann wrote: > - Jan 19 7:49 PM: commit > https://github.com/php/php-src/commit/0df92d218e88a0 pushed to > php-src > > Look how the commit is exactly a revert of the timelib PR that Derick > Rethans closed and locked just the day before. > Ahh so it seems to be a big misunderstanding. Derrick didn't undo your commit. Derrick simply synched timelib. The file in the commit belongs to timelib not PHP. Derrick is the author and the maintainer of that library. As the author, he decides on what is merged into timelib. You submitted a PR that was declined. No big deal. But the file should not be modified in PHP because PHP has a readonly copy of that library. It will be overwritten whenever Derrick syncs it up. I'm not sure what impact this has on PHP, but as long as it compiles fine and there are no bugs, I see no reason to pressure the maintainer of timelib library to change their code. If it meant that the current release of timelib suddenly becomes inoperable with PHP then we would have an issue. Regards, Kamil
Re: [PHP-DEV] 'Uninitialized' creates a lot of cluttering
> But because of the typed properties, you have to initialize them before you can access them. I think that is cluttering up the code. It's not cluttering code. You don't need isset if you do it properly. You have a bug if your code tries to access an uninitialized property. > From a programmer's perspective, the property is declared and should be accessible. Even if it has no value. There should be no difference between typed and none-typed properties for this. You cannot fetch value of something that has no value. The property is declared, but the value was never set. There is a difference because, as I explained it earlier, untyped properties were implicitly nullable and had a default null value. Typed properties do not have an implicit default value, and they do not hold any value until the programmer assigns some value. The property is accessible, but it doesn't have any value, not even null value.
Re: [PHP-DEV] 'Uninitialized' creates a lot of cluttering
Hi Lydia,
I understand where you are coming from because I encountered this a few
times myself, but every time it was actually because I was doing something
wrong. The reason for this limitation is actually very simple and logical.
Let me explain.
When you use untyped properties, the type is not restricted so every
property can be nullable by default. It's very simple for the language to
have NULL as the default value for all untyped properties.
When using typed properties, the language cannot use NULL as the default
anymore because the type might not allow NULL, e.g public string $name
allows only string values. Unless you assign some string value to it, the
language will not initialize it with any value. If you need the property to
have a state indicating no value, you can make it nullable and assign NULL
as the default value.
What you are proposing is actually not acceptable from the type system's
point of view. We cannot add a new syntax for assigning default values to
type properties. It might make sense in a very limited scope, e.g. public !
int $number; defaults to 0, but in any other more complex scenario, this
fails miserably. Consider this example:
class Test {
public ! MyObject $prop1;
public ! int|false|null $prop2;
}
In the example above, what default values could be assigned to the
properties? The correct answer is none. You cannot have a default object,
nor can you pick a default value from the union of three types. There is
simply no way to determine the default value. So if we had a new syntax
like this, it would be severely limited to only the simplest scenarios.
This would create a new inconsistency for the benefit of using a single
character instead of assigning the value. There would be no benefit to
introducing such inconsistency to the language.
It is the job of the developer to specify the default type. Some things can
be left for PHP to infer, but when it comes to the default property value,
the developer needs to assign it.
You said that an isset is necessary when using typed properties. I would
argue that an isset is not needed. Using isset with typed properties is a
code smell in many circumstances. If the property can be unassigned, the
developer should use a sentinel value such as null to indicate this. If the
property is always expected to hold a value, then the code should not allow
a path to access it before it's initialized.
Kind Regards,
Kamil
Re: [PHP-DEV] RFC proposal: function array_filter_list() to avoid subtle bugs/workarounds
Hi Sergii, First of all, let me say that I am glad more people are willing to give back to the PHP language. I'm happy you decided to join the ML. However, the change you are proposing is unlikely to be well-received. PHP already has too many functions. It is known as a kitchen sink[1]. I don't think we need list-variants of the array functions. As you noted yourself, it can be simply implemented with array_values(). If we do this one then next someone will say what about array_diff() with a list? Most of the functionality can be implemented in userland and it's usually the preferred way. If we are going to add a new function to PHP, it must have a very good reason to be implemented in C. array_is_list() had a very good explanation: performance. Ideally, we would have a separate type for List, but... it can easily be implemented in userland so we are back to square one. While PHP's arrays are something of a Frankenstein's monster, they work well as an internal implementation detail of other data structures. Adding more array_* functions is something that many of us would want to avoid. Regards, Kamil [1]: https://web.archive.org/web/20181107125816/http://www.mcguirehimself.com/?p=117
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
I don't think it's such a huge issue as you make it to be. The documentation states this only as an alternative: https://phpspreadsheet.readthedocs.io/en/latest/topics/accessing-cells/#looping-through-cells-using-indexes It also mentions the pitfalls. I doubt many users would prefer that "alternative" given that the recommended way is simpler and does the same thing. I also don't think that performance would come into play here. Any difference would be insignificant. I believe that the benefits of the deprecation outweigh any potential extra work the developers may have.
Re: [PHP-DEV] RFC: rules for #include directives
I am in both camps. I think some slight cleanup might be in order, but not how you are proposing it. First of all: - I am against forward struct declarations. I think they decrease code readability and should be avoided. - I am against putting comments on #includes. Comments are noise in code and often go out of date. Especially in a situation like this where the comment is physically far away from the code that introduced it. To take the example: > #include "zend_portability.h" // for BEGIN_EXTERN_C What if in future the need for BEGIN_EXTERN_C disappears? Who is going to remember to update the comment? As you said yourself, this refactoring has no practical effect on compilation times. But your RFC states this as one of the advantages. This is misleading. Another advantage listed is "more correct code". Perhaps it is, but does it mean that the current situation is likely to cause more frequent PHP bugs? Would this refactoring help in finding PHP bugs more quicker? Others have raised a valid point that PHP bugs are fixed in earlier versions and then merged up into master. What you are proposing is going to lead to issues with merging. And I don't mean merge conflicts, because includes rarely change in bug fixes. I mean things like a bug fix using a symbol that hasn't been used in the file but is included through one of the more generic headers. Once such a commit is merged into master, it may turn out that the symbol lacks a new include. This adds unnecessary work for bug fixers who will now have to verify this and find the appropriate include during merges. So maybe reduce scope of this refactoring? Do it only where it's strictly necessary. Don't use forward declarations or comments. Or maybe have all ZEND headers included with a single header? Refactoring needs to make developers' life easier and not just be done for the sake of following best-practice.
Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
I like this proposal and I support making the language consistent. I wasn't aware there were so many inconsistencies with increment/decrement operators. When I read the RFC I was a little sceptical about the deprecation of string increment functionality. It's something I used in the past and I see no easy upgrade path. However, after reading this thread and thinking it over, I realize that deprecation is the right way to go. Someone said that it's useful when working with Excel. Excel uses bijective base-26 system. PHP does not. I cannot even explain what logic governs PHP string increment functionality. ``` $s = "az"; var_dump(++$s); // string(2) "ba" $s = "a9"; var_dump(++$s); // string(2) "b0" $s = "99"; var_dump(++$s); // int(100) $s = "zZ"; var_dump(++$s); // string(3) "aaA" $s = "9D9"; var_dump(++$s); // string(3) "9E0" $s = "9E0"; var_dump(++$s); // float(10) $s = "CHEAP BED"; var_dump(++$s); // string(9) "CHEAP BEE" ``` Strings should not be incrementable unless they are numeric strings. The current "feature" is more like a bug from xkcd comic. https://xkcd.com/1172/ But as there is a real need for a similar functionality, for example when working with Excel, I would propose to add a class into the language that is able to calculate and iterate any bijective base system. It needs to have a clear functional spec and should support both increment/decrement operators as well as iterators. I see this as the only way out of this mess. This RFC needs to pass, but it cannot pass without an alternative for people who actually use this "feature". The PHP manual says: "The increment/decrement operators only affect numbers and strings. Arrays, objects, booleans and resources are not affected. Decrementing null values has no effect too, but incrementing them results in 1." But that's not true. You cannot increment an array or resource as it would trigger an error. But incrementing false/true doesn't generate any errors. It's very inconsistent and misleading.
Re: [PHP-DEV] RFC: rules for #include directives
Have you done any benchmarking in terms of build time? Is there any tangible difference or is it only theoretical?
Re: [PHP-DEV] RFC: rules for #include directives
Hi, Did you create an RFC already? Or is this RFC-like discussion? In either case, if you are asking community to come to a decision, we need to see some background. Why do you want to change this? What's the benefit? What's the impact on other maintainers, especially extension maintainers? Do you see any downsides to your new approach? Regards, Kamil
Re: [PHP-DEV] [RFC] [Discussion] SQLite3: remove warnings, move to exceptions
Hi, I don't think we should be removing such large chunk of functionality in a minor version. If you want to change the default to throw exceptions, that's ok. But I wouldn't remove the method in 8.3 or 8.4 and only remove it in 9.0. What is the advantage to removing the Warning mode? Regards, Kamil
Re: [PHP-DEV] Should the engine be able to pass variables by reference of userland functions
Hi, I am not sure if we should still support it. But I don't think it's unthinkable to expect such feature from PHP. However, personally, I don't find pass-by-ref that useful in general. The question is whether this feature is used a lot in the wild. If we decide to drop support for this, it should probably go through a deprecation phase. Regards, Kamil
[PHP-DEV] Sanitize filters
Hi Internals,
For quite some time now, PHP's sanitize filters have "Rustled My Jimmies".
These filters bother me because I can't really justify their existence. I
can understand that a few of them are sensible and may come in handy, but I
would like to talk about some of these in particular.
In PHP 8.1, we have deprecated FILTER_SANITIZE_STRING which I deemed to be
a priority due to its confusing name and behaviour. The rest is slightly
less dangerous, but as was pointed out to me in a recent conversation with
a PHP developer, these filters are all very confusing.
I would like to have some opinions on the following filters. What do you
think we should do with them? Deprecate? Fix? Provide better documentation?
---
*FILTER_SANITIZE_ENCODED *- "URL-encode string, optionally strip or encode
special characters."
Now, what does that mean? PHP has two functions for URL encoding: urlencode
used for encoding query-string parts, and rawurlencode used for encoding
any other URL part (two different RFCs are followed by these functions).
Which of these RFCs is applied in this filter? Furthermore, the description
says that "special characters" can be stripped or encoded. Is one of these
actions the default and the other can be selected by a flag or are both
optional? What are these special characters? Are they special in the
context of URL? If so, why did we encode them first? If these are HTML
special characters (there's no single definition of special HTML chars),
then why does this filter encode them if the filter is for URL
sanitization? What does backtick have to do with any of this
(FILTER_FLAG_STRIP_BACKTICK)?
*FILTER_SANITIZE_ADD_SLASHES - "*Apply addslashes(). (Available as of PHP
7.3.0)"
This filter was added as a replacement for magic_quotes filter. According
to PHP documentation, addslashes is supposed to be used when injecting PHP
variables into eval'd string. Real-life showed that this function is used
in a lot of places that have nothing to do with PHP's eval. I am not sure
if the sanitize filter is misused in a similar fashion, but judging from
the fact that it was meant as a replacement for magic_quotes, my guess is
that it's very likely still abused.
*FILTER_SANITIZE_EMAIL *- "Remove all characters except letters, digits and
!#$%&'*+-=?^_`{|}~@.[]."
Which RFC does this adhere to? It strips slashes and quoted parts, doesn't
allow IPv6 addresses and doesn't accept RFC 6530 email addresses. This
filter is ok for simple usage, but it isn't true to any known specification
AFAIK.
*FILTER_SANITIZE_SPECIAL_CHARS *- "HTML-encode '"<>& and characters with
ASCII value less than 32, optionally strip or encode other special
characters."
What's the intended purpose of this filter? "Special characters" are still
not clearly defined, but at least it's more clear than
the FILTER_SANITIZE_ENCODED description. Same question about backticks
though: why? Why encode ASCII <32 chars?
*FILTER_SANITIZE_FULL_SPECIAL_CHARS *- "Equivalent to calling
htmlspecialchars() with ENT_QUOTES set. Encoding quotes can be disabled by
setting FILTER_FLAG_NO_ENCODE_QUOTES. Like htmlspecialchars(), this filter
is aware of the default_charset and if a sequence of bytes is detected that
makes up an invalid character in the current character set then the entire
string is rejected resulting in a 0-length string. When using this filter
as a default filter, see the warning below about setting the default flags
to 0."
Not to be mistaken with FILTER_SANITIZE_SPECIAL_CHARS. As long as it's not
used with filter_input(), it's the least problematic. We
have htmlspecialchars() though, so how useful is this filter?
*FILTER_UNSAFE_RAW *- What makes it unsafe? Why isn't this just
called FILTER_RAW_STRING? If the value being filtered is something other
than a string, what will this filter return? Integers, floats, booleans and
nulls are converted to a string, Arrays and objects make the filter fail.
---
Let's quickly mention the filter flags.
The FILTER_FLAG_STRIP_LOW flag will also remove tabs, carriage returns and
newlines as these are all less than 32 ASCII codes. When is this useful and
expected?
The FILTER_FLAG_ENCODE_LOW flag "encodes" ASCII <32 codes presumably into
HTML entities, although that's not specified anywhere in the PHP manual.
The word HTML does not appear on the
https://www.php.net/manual/en/filter.filters.flags.php page. What do these
characters look like when presented by HTML? When is it ever useful to use
this flag?
FILTER_FLAG_ENCODE_AMP & FILTER_FLAG_STRIP_BACKTICK - why is this even a
thing?
Due to flags, FILTER_VALIDATE_EMAIL will happily validate email addresses
that would be otherwise mangled by FILTER_SANITIZE_EMAIL.
These are just the things I found confusing and strange about the sanitize
filters. Let's try to put ourselves in the shoes of an average PHP
developer trying to comprehend these filters. It's quite easy to shoot
yourself in the foot if you try to use them. The PHP manual doesn't do a
good job of
Re: [PHP-DEV] Increase maximum size of an uploaded file to 50Mbyte
I have it set to 32MB and nobody has complained yet. I think it might be a sweet spot between security and usability out of the box.
Re: [PHP-DEV] RFC json_validate() - status: Under Discussion
What is the reasoning behind the name? I can't find it explained in the RFC. What about other alternatives like is_json or validate_json?
Re: [PHP-DEV] array_merge() vs array unpacking performance
Hi David, It would be useful if you could provide your measurements and the way you arrived at such results. A quick test doesn't seem to support your findings: https://3v4l.org/v5m9f#v8.1.8 There are already a number of optimizations in array_merge. It might depend on the actual test data that you used. Maybe a specific path needs to be optimized. Please provide some more details. Regards, Kamil
Re: [PHP-DEV] [RFC] [Under Discussion] New Curl URL API
Please do not add yet another thin wrapper of an underlying C API. PHP is not a drop-in replacement of C. PHP is a much higher-level language. Developers should not have to understand how the underlying library works to be able to use PHP. We need to move away from thin C wrappers as a language. PHP should abstract more, not less, of C code. The new API doesn't have to have exactly the same names as the C library. Please follow PHP naming conventions and implement OOP-based API.
Re: [PHP-DEV] [RFC] Make the iterator_*() family accept all iterables
Just linking up the previous discussion around this topic: GH: https://github.com/php/php-src/pull/3293 ML: https://externals.io/message/102313
Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements
First of all, thank you for working on this. I wanted OO API for Curl for a long time. Exceptions all the way. Code that's not using exceptions is usually more clunky and error-prone. The new OO API shouldn't have the possibility to return null/false on error. This is considered a thing of the past nowadays and the majority of developers prefer exceptions on error. Please do not add any more procedural APIs. The existing ones should be deprecated and removed at some point in the future. Regards Kamil
Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions
Hi Andreas, Has any case study been done already about how it will affect existing codebases? Regards, Kamil
Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation
+1 on removing variable variables as soon as possible.
Re: [PHP-DEV] Allowing NULL for some internal functions
Hi Craig, > No, there is an inconsistency which leads to a backwards compatibility issue, and I'm trying to fix it. Which inconsistency exactly do you have in mind? The discussion is about passing arguments to functions. We are not discussing type juggling or type casting. To clarify the whole thing let's list out the key points: - PHP has a concept of scalar types consisting of these four types: string, int, float, bool - PHP has type juggling that converts the value to the type required by the context in which it is used. The behaviour is defined for scalar types, but often undefined for other types (see juggling to array) - PHP lets users cast values to a specified type. There are 7 (+1) available casts in PHP (disregarding aliases). Casting to scalar types from scalar types is defined. Casting to scalar from other types is partially defined and causes undefined behaviour in some cases. Warnings are generated in certain situations (e.g. array to string) and fatal errors when the cast cannot be performed at all. - PHP has a special type called NULL with a single value NULL. It's not a scalar and it's not a stand-alone type. Casting to NULL is not possible. For all intents and purposes, NULL value represents a variable with no value. For this reason, converting to other types generally does not cause any notices, warnings or errors. However, using NULL might generate warnings or errors depending on an operation. e.g. `null[0]`, `null->scalar` or `[...null]` - PHP has a concept of strict typing. It applies only to scalar parameters. By default, PHP will coerce values of the wrong type into the expected scalar type declaration if possible. NULL being a non-scalar value doesn't coerce in non-strict mode. Neither does array, object or resource. See https://3v4l.org/WZdQC The only inconsistency is that PHP's internal functions silently accepted NULL values for non-nullable parameters. This will be addressed in PHP 9.0. Changing the signatures of some functions might be reasonable but, as few others have said, it's not the solution we want to see because it feels like a hack. As I have also pointed out off-list, in many cases making the parameter type nullable would not make any sense as passing null to certain functions is a clear bug. It would also have an impact on strict typing! We could also reclassify NULL as a scalar type but that would be a fundamental language change. It would likely be a bigger BC change than fixing the current inconsistency. By the way, your statement that "Coercion works for string/int/float/bool, *and* NULL." is invalid. Coercion is defined only for scalar types as I have explained above. Type juggling for most types from NULL is defined, but that is not what we are discussing. Regards, Kamil
Re: [PHP-DEV] Re: Proposal for RFC to remove undefined array index warning when used ina ternary
I just wanted to add that the following $name = $_POST['name'] ?: 'Default Name'; with existence check would be $name = $_POST['name'] ?? null ?: 'Default Name'; You don't need empty(). I would be against changing the behaviour of elvis/ternary operator. However, I remember seeing past suggestions to implement another operator. One that would fill the gap between null-coalesce and elvis operators. If I recall correctly, most of the time, these proposals end in consensus that such operator isn't really needed. See https://externals.io/message/89292#89292 and https://externals.io/message/101606#101610 Maybe, it would be worthwhile to refresh a discussion about adding such operator to the PHP language?
Re: [PHP-DEV] RFC proposal to deprecate crypt()
I think it's a great idea to deprecate crypt(). I wouldn't want anyone to use it in a new code. For legacy applications, we are giving them enough time to upgrade their password storing policy. Also, it's not like we are removing support for hashing in general from PHP, we are just deprecating a function that should not be used for password hashing. There's a suitable replacement and it's also possible to create a shim for the crypt() function if one really needs it. I also recommend reading this article https://www.michalspacek.com/upgrading-existing-password-hashes
Re: [PHP-DEV] [VOTE] RFC: Remove support for libmysql from mysqli
> good job! can we do PDO_MYSQL next? if that also goes away (seems likely), all libmysqlclient-specific code can be removed i think Feel free to create an RFC. I was only interested in doing this for mysqli because that's where I saw value in doing it. The support for libmysql was causing problems for mysqli and removing it is definitely an improvement. PDO doesn't have such burning issues and the existing code works almost as well as with mysqlnd. But I would vote in favour of dropping libmysql support for PDO too. Regards, Kamil
Re: [PHP-DEV] [VOTE] RFC: Remove support for libmysql from mysqli
The voting has now ended. The RFC has been unanimously accepted (30/0). Since PHP 8.2 it will not be possible to compile mysqli with libmysql. Kind regards, Kamil >
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
I am on the fence about this change? How about we remove the warning from pre-increment operator and turn the rest into warnings? Is this possible? Would it be a good compromise?
Re: [PHP-DEV] [Strawpoll] Promoting redefining constant to exception
A constant is a value that, unlike a variable, cannot be reassociated with a different value. A properly written software should never redefine constants. The possibility of redefining constants in PHP should be considered a bug rather than a feature. Constants are not good for configuration values that can be changed. A proper data structure should be used instead. Constants should never have to be redefined, either by the software itself, its tests or its extensions. Constant values must remain the same under all circumstances otherwise they are no longer constants. +1 to remove it in PHP 9.0
[PHP-DEV] [VOTE] RFC: Remove support for libmysql from mysqli
Hi Internals, I have opened voting on https://wiki.php.net/rfc/mysqli_support_for_libmysql Voting ends in 2 weeks. Kind regards, Kamil
Re: [PHP-DEV] RFC: Remove support for libmysql from mysqli
Hi Internals, Just a reminder that if there are no objections I will start a voting phase on this RFC in 2 days. Regards, Kamil
[PHP-DEV] RFC: Remove support for libmysql from mysqli
Hi Internals, Some time ago I wrote to the list asking if there are any objections to removing support for libmysql from mysqli. As I haven't heard any compelling arguments, I prepared a PR and RFC. https://wiki.php.net/rfc/mysqli_support_for_libmysql https://externals.io/message/116730 Regards, Kamil
[PHP-DEV] Drop support for libmysql with mysqli
Hi Internals, I would like to propose dropping support for libmysql from mysqli and ask for opinions on how this could be best achieved. At the moment both mysqli and PDO_mysql support building against mysqlnd and libmysql. The default is mysqlnd since PHP 5.4. Mysqlnd is the recommended library to be used with PHP. There are plenty of differences between the two libraries. Removing support for libmysql would allow PHP to simplify the code and unit tests. Advantages of mysqlnd include: - Bundled with PHP - Uses PHP memory management which helps to monitor memory usage and improve performance - Provides functions that make life easier, e.g. get_result - Returns numeric values using PHP native types - The functionality does not depend on the version of the external library - Optional plugin functionality - Asynchronous queries Advantages of libmysql: - Auto-reconnect is possible (this functionality is intentionally not supported by mysqlnd due to how dangerous it is) However, libmysql has many disadvantages: - It does not use PHP memory model. It doesn't respect the memory limits, does not count towards memory stats and cannot utilize internal optimizations - PHP does not know the value size and needs to allocate as much memory as the field length. This makes it very difficult to use with long columns like LONGTEXT - Doesn't support get_result, bind-in-execute, and fetch_all & next_result (prior to PHP 8.1). This makes libmysql the smallest common denominator for applications like DBALs which can't rely on these easy to use functions and instead have to perform strange workarounds resulting in more complex code and worse performance, even when not using libmysql - Functionality differs from version to version. Depending on which libmysql version PHP was compiled with you might be able to use a certain feature or not. - Many failing tests. Some of these tests could be fixed with SKIP or conditional checks, but some fail because of incompatibilities. - Memory leaks. These might even be considered security vulnerabilities - Not available on Windows While many distributions offer PHP with mysqlnd as default there are some that make it confusing for new users. In particular, when using cPanel, users are confused about how to enable mysqli with mysqlnd. Instead of enabling mysqli they have to enable nd_mysqli extension which is counterintuitive. In 2019, Nikita suggested dropping the support or finding a maintainer for it [1]. So far, nobody has come forth to improve mysqli support with libmysql. It has become clear that there is not much demand for it. If people were using it, then someone would eventually fix the bugs. PHP doesn't have CI jobs and is not testing for the failing unit tests. We can consider mysqli with libmysql as not supported configuration, but that leaves us with the problem that PHP still makes it possible to compile with libmysql and the PHP manual list it as a viable option. I would propose to drop the support for mysqli with libmysql, but it would be nice to do it with a deprecation period. I am not sure if it is possible to have a deprecation period. If we raise a deprecation during compilation, users won't see it. If we raise it during usage, we will flood their error logs. I think we can keep support for libmysql with PDO_mysql as it has been fixed and seems to be working ok. I am not sure what benefit it brings, but if it doesn't harm then there's probably no reason to drop it. Certainly, we should encourage usage of mysqlnd with PDO as it should offer better performance and reliability. We don't control the version of libmysql used in the compilation process so while it works in CI jobs, it might not work 100% when used with other versions. e.g. MySQL's libmysql vs MariaDB's libmysql I am also looking to find out if anyone knows of any other advantages of mysqli with libmysql or is intentionally using mysqli with libmysql in their production systems. [1]: https://externals.io/message/106086 Further reading: https://externals.io/message/55084 Kind Regards, Kamil Tekiela
Re: [PHP-DEV] Re: [VOTE] Deprecate dynamic properties
Hi Brady, This is a little bit overly dramatic. This isn't such a huge change that would affect 50% of existing projects. It's likely to affect a small number of projects in a very limited way. It's also not true that developers will slap #[AllowDynamicProperties] on every class. That would imply that every class in their project is using dynamic properties. That would be absurd. If it's truly the case that every class in 50% of the projects uses dynamic properties then we should not consider this RFC at all. The whole premise of it is that it's highly unlikely that many people are using dynamic properties on purpose. It's true that many old unmaintained projects might use it as a feature, but the keyword is "unmaintained". I would not trust dependencies that haven't been kept up to date for a few years. PHP has had many breaking changes over the years. PHP 8.1 introduced a much more annoying deprecation: Deprecate passing null to non-nullable arguments of internal functions. This one I would have no trouble believing that it impacts 50% or even the majority of PHP projects. Dynamic properties compared to this should be a piece of cake. I doubt that having to add a single attribute to a selected few classes would be such a major issue that projects would decide to stay on PHP 8.1 rather than upgrade. It's not comparable to Python 2/3 situation IMHO. I would be interested to know some numbers from Snipe-IT. Have you done a preliminary analysis of your codebase of how many classes are actually using dynamic properties? From a brief look, I can see that usually most properties are declared. Regards, Kamil
Re: [PHP-DEV] PHP 8 Release Announcement Page
I would suggest option number 5. Leave it as it is. Many people are still not aware that PHP 8 has been released. If that's not possible, then we should keep the page (opt 3), otherwise we will be breaking links to it, e.g. on Stack Overflow. Adding PHP 8.1 alongside would be great, but we already have upgrade pages, so I'm not sure the effort is worth it.
Re: [PHP-DEV] Proposal: &$result_code=null parameter in shell_exec()
Hi Luca, How will this change be reflected in its alias, the backtick operator? If the plan is to change the signature of shell_exec() then the backtick operator will not behave identically anymore. Am I correct? Regards, Kamil
Re: [PHP-DEV] Is there an RFC/discussion for ::class being a specific type?
Hi Dusk, Perhaps, you misunderstood me. Take a look at the documentation https://www.php.net/manual/en/language.oop5.basic.php#language.oop5.basic.class.class ::class is just a compile time transformation. It will give you the fully qualified name of *something* as a string literal. The only exception to this is when using ::class on objects, as this is a runtime transformation, and when using with keyword static. When ::class is used with a class name, it will give you the name of that class as a string. When used with a name of a function, it will give you the name of that function as a string. When used with a string, it will give you that string as a string. See this example https://3v4l.org/EKnEd The fact that this gives you a callable is just coincidental with all strings being callable in PHP. The reason why it works right now is because a string can represent a name of a class, interface, trait or function. If we were to replace the transformation with something else, like it is proposed here, we would have to ensure that it is as versatile as a plain string. Otherwise we would be losing functionality.
Re: [PHP-DEV] Is there an RFC/discussion for ::class being a specific type?
Ok, but a popular usage is also with functions. For example, strlen::class.
What should the compiler use in this case?
Replacing a string with an object of a strigable class is not the same. Say
I have code like this:
function callFoo(callable $func) {
echo $func('bar');
}
callFoo(strlen::class);
This would trigger an error as the ClassName is not an invokable class.
Re: [PHP-DEV] Is there an RFC/discussion for ::class being a specific type?
Interesting, but what would such a type actually be? How would PHP check the type? What would be the rules? At the moment, ::class is just a preprocessor macro. It is not part of the runtime. It also doesn't mean the name of the class. It just means "textual representation of the value on the left". For example, this is valid: echo "string"::class; You can use ::class on almost anything that the compiler would treat as a string literal. In the end, it will be compiled down to a string. It is handy to think of ::class as ::text or ::name. I don't think we could enforce class type without actually asking PHP to check if class exists. You can use static analysers for this (see class-string), but I doubt it will be possible in PHP.
Re: [PHP-DEV] [RFC] Deprecate dynamic properties
I would be very sad to see this RFC not go through. I have voted Yes as I believe this "feature":is a bug that needs to be fixed. There is also an opt-in proposed for people who really do consider it a feature. I don't see why it would cause much trouble for maintainers of OSS. At the moment it is proposed to make this change in PHP 9.0, which is a couple years away. That is a lot of time to fix the code. The deprecation message will inform us about the number of uses, whether accidental or intentional. If we decide that removal of this feature would cause too much disruption, could we not have RFC in PHP 8.3 to remove the deprecation? Deprecated or not, I still believe that OSS should avoid dynamic properties. They are really difficult to identify, even with static analysers. Having the deprecation message would at least help us identify where dynamic properties were used, so that we can fix it.
Re: [PHP-DEV] Change of $depth behaviour in json_encode() on PHP 8.1
Hi Benjamin, This is a bug. Please report it on https://bugs.php.net/ See https://3v4l.org/vFgh0 https://github.com/php/php-src/commit/f9f8c1c79cac1b03279190e0c5513a51881615f9 https://github.com/php/php-src/pull/6811 Best Regards, Kamil
Re: [PHP-DEV] [RFC] Random Extension 3.0
Yes, I know the reason why we use MT19937 as the name, but this is not really very user-friendly name. The actual algorithm could be documented in the PHP manual but the name could be better. The problem with this name is that most users simply don't care about the algorithm being used. At least that is what it was until now. For example https://phpmanualmasterpieces.tumblr.com/post/65965628369/so-php-such-documented What I think would be better is to not provide two versions of MT at all and just call it MersenneTwister. Users who require backwards compatibility with rand() can do so in userland or keep using rand() for the moment. Naming is a very minor problem, so I would be ok either way, but I am just voicing an opinion that having two classes with 32 and 64 at the end, in this day and age, will be very confusing for users. Better to avoid such things in PHP.
Re: [PHP-DEV] [RFC] Random Extension 3.0
Please don't add more answers to the class name. There is already going to be a backlash if we name it "MT19973" instead of "MersenneTwister"
Re: [PHP-DEV] RFC Concept: "Import" of simplied string manipulation and other instructions from ASP Classic
Hi Daniele, Thanks for reaching out to internals. I am curious about your proposal. Could you please provide some examples of what you think was great in Classic ASP that you would like to see implemented in PHP? If you have implemented polyfills in PHP for them, could you share them with us? Regards, Kamil
Re: [PHP-DEV] BC breaking changes in PHP 8.1
I just want to point out that PHP does not follow semantic versioning. It never did and there are no plans to start following it now. Breaking changes were made in all previous versions, both major and minor. The only time when we try to avoid breaking changes is in patch releases. These are extremely uncommon.
Re: [PHP-DEV] Make strtolower/strtoupper just do ASCII
+1 from me. I wasn't even aware that these functions are locale-dependent until recently. I see an added benefit that we could add them to the optimizer once they are no longer locale-dependent. What would happen to users who really need the locale-dependent functions? Do we offer some workarounds?
Re: [PHP-DEV] Alias stdClass to DynamicObject?
Hi Marc, The name seems to be ok IMHO. Even though it is a class, the main use case is to denote an object that was created dynamically rather than through an instantiation of a class. And I know that a lot of usage comes from people directly creating new instances of stdClass but if you do that then you can use proper classes also (with Nikita's proposal to deprecate dynamic properties one would have to use a class with defined properties to do the same). It's not unheard that a class has "object" in the name. e.g. https://docs.oracle.com/javaee/7/api/javax/json/JsonObject.html or https://docs.microsoft.com/en-us/dotnet/api/system.json.jsonobject?view=dotnet-plat-ext-5.0 The name DynamicObject is also used in other languages. https://docs.microsoft.com/en-us/dotnet/api/system.dynamic.dynamicobject?view=net-5.0 The word "Dynamic" semantically explains the purpose of the instance of such class: it has no fixed structure. We could call it Map or Dictionary, which would also be fitting, but in doing so we are opening up the scope of this RFC. How much more functionality does PHP need? What would be the goal of it? PHP has tons of functions for working with arrays. If we introduce another type like Map then it would be expected that a set of methods be added to it. This sounds similar to scalar objects. And while it would be nice to have such kind of functionality in PHP, it would also be a lot of work to implement it. If we already have associative arrays, do we really need another structure to do the same thing? I think it would be prudent to first understand why people are using stdClass in the first place. From my experience, most of the time people who work with stdClass don't expect it to have any methods. It's just a container for data just like an array, but with a different syntax. It's not much more different than an anonymous class. The goal of Nikita's proposal is to retain the functionality of dynamically assigning properties to an object after deprecating dynamic properties on all other objects. The new class DynamicObject would be a special type of class that would retain this functionality. Thus, the name fits perfectly. A DynamicObject is a class whose properties can be created dynamically. Regards, Kamil
Re: [PHP-DEV] Adding a way to disable the stat cache
It's WSL2 uname -r 5.4.72-microsoft-standard-WSL2
Re: [PHP-DEV] Adding a way to disable the stat cache
> It would be great if someone on Windows and macos could repeat this experiment I ran this on Windows and I got the following results: Native Windows build: Without cache real0m31.170s user0m0.000s sys 0m0.000s With cache real0m0.694s user0m0.000s sys 0m0.000s Ubuntu WSL: Without cache real3m8.695s user0m7.009s sys 0m18.819s With cache real0m0.707s user0m0.562s sys 0m0.010s I am not sure how to interpret it. I doubt that any system would actually perform 1 million operations on the same file, but I can definitely see a noticeable difference.
Re: [PHP-DEV] Alias stdClass to DynamicObject?
Hi Nikita,
I think this might be a good idea, but I would like to propose yet another
variant.
Replace stdClass with DynamicObject and keep stdClass as an alias. It can
be deprecated in 8.3.
If we only add an alias, I am afraid that it will not catch on quickly
enough. What I am proposing is that the cast to object will create
DynamicObject by default.
$arr = [1,2];
var_dump((object) $arr);
Output:
object(DynamicObject)#1 (2) {
["0"]=>
int(1)
["1"]=>
int(2)
}
It will break unit tests and it might break some code (e.g. `if ('stdClass'
=== $class)`), but it will help people understand what is the preferred
name going forward without deprecating it right now.
Regards,
Kamil
Re: [PHP-DEV] Sodium - Stream Counter API
Development for 8.1 is already closed. You can only target this for 8.2
Re: [PHP-DEV] Re: [RFC] Add parse_query_string as an alternative to parse_str
Hi Internals, During my research into this topic, I discovered that there exists a multibyte variant of this function in mbstring extension. This raises the question: should we add a corresponding multibyte variant of http_parse_query() to mbstring? Is there any usage in the wild of mb_parse_str()? I have even asked a question on Stack Overflow about this topic https://stackoverflow.com/questions/68761695/can-mb-parse-str-produce-different-results-than-parse-str To me, it doesn't look like parse_str() is useful anymore, but I come from Europe where things happen mostly using a single encoding. I am not aware of any problems that parse_str() might have when it comes to multiple encoding types. In fact, when looking at the whole input/output encoding feature of mbstring I am getting a feeling that this is some niche feature that almost nobody ever uses. While mbstring is useful for dealing with different encodings, I am not sure if it is common for HTTP requests to be encoded with anything else than UTF-8. I would appreciate some input from experts who know more about mbstring and encodings. Regards, Kamil >
Re: [PHP-DEV] Re: [RFC] Add parse_query_string as an alternative to parse_str
Hi Internals, Thanks for all the feedback. I have changed the name to http_parse_query as it looks like more people prefer that name. I have also updated https://wiki.php.net/rfc/parse_str_alternative for 8.2 (sorry for the confusion) and I added open points. I hear two concerns currently about this RFC. Please note that my intention was to provide a simple drop-in replacement. However, I agree that there is a lot of room for improvement in this area, so I highly appreciate your comments on how we can best tackle these open points. I will not open this RFC for voting any time soon, as I want to let the conversation run through to see what other options/concerns people have. Please feel free to share your comments on what you think is the right path to improve this functionality in PHP. Regards, Kamil
Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str
btw why isn't foo.bar=123 decoded to array("foo.bar"=>123); ?
> this looks pretty bad to me https://3v4l.org/6Wa23
Hi Hans,
This is because variables in PHP that contain the concatenation operator or
space are much more difficult to access. See https://3v4l.org/vUBWK
As the primary purpose of parse_str was to register globals from a query
string, it follows the same logic as your normal POST/GET/COOKIE parsing.
See https://stackoverflow.com/a/68742/1839439
Perhaps, instead of adjusting this behaviour only for the new function, we
could remove this behaviour as a whole, given that it is a remainder of the
long-forgotten register globals? I don't see any use for it anymore, as all
parsed input is only available in the form of an associative array. People
who extract $_POST can suffer the consequences of their own actions...
Regards,
Kamil
Re: [PHP-DEV] Re: [RFC] Add parse_query_string as an alternative to parse_str
Hi Internals, I have added implementation for https://wiki.php.net/rfc/parse_str_alternative. If there are no other comments, I would like to start voting on Saturday. Regards, Kamil
Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str
Hi All, Thanks for the feedback. I decided not to pursue this for PHP 8.1, but I still think it is a good idea. As Nikita explained Sara's suggestion might not work at all. While it is trivially easy to abstract this function in userland the aim is to clean up PHP. This wouldn't add new functionality to PHP, but rather provide a cleaner implementation with a self-documenting name. I don't know when we can start RFCs for PHP 8.2 but I will try to write an implementation for this RFC in a couple of days and ask for a vote. Regards, Kamil >
Re: [PHP-DEV] [RFC] Deprecate boolean to string coercion
Hi George, As someone who has fallen victim to this silent bug in the past, I think I would be on board with this change. Why only implicit casting? If we compare this to the array-to-string casting then the warning happens for both. It would be more consistent to deprecate both implicit and explicit. I'd imagine it would also be easier to implement. I'd say that printf() family of functions should also throw the deprecation notice, even if we only deprecate implicit conversion. I am under impression that most of the time when this kind of conversion happens the expected outcome is either 0 or 1. For example, when storing a boolean flag to sqlite database. Could we not change the false value to 0 instead of deprecating? Regards, Kamil
