Hi All,
The voting has ended. RFC was accepted unanimously with 29 votes.
Regards,
Kamil
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.
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
>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
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
If there are no more comments, I would like to put this RFC to vote in
the next two days.
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,
-- 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
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
this RFC is to reduce potential
security pitfalls.
Regards,
Kamil Tekiela
I love it!
When is CurlMultiException and CurlShareException thrown? I feel like
this part in general is not very clear in the RFC.
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:
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
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
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
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.
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
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
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
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
> 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
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
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
You must enable bleeding edge.
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
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.
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
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
Hi,
I don't understand what you are proposing and what problem you are trying
to fix. The RFC is not explaining things well.
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.
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
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
>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
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
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
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,
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.
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
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
>
> 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
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
> 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
g 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
>
> 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
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
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
> 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
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
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
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
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
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
Have you done any benchmarking in terms of build time? Is there any
tangible difference or is it only theoretical?
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
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,
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
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
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.
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?
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
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.
Just linking up the previous discussion around this topic:
GH: https://github.com/php/php-src/pull/3293
ML: https://externals.io/message/102313
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
Hi Andreas,
Has any case study been done already about how it will affect existing
codebases?
Regards,
Kamil
+1 on removing variable variables as soon as possible.
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
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
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
> 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
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
>
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?
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
Hi Internals,
I have opened voting on https://wiki.php.net/rfc/mysqli_support_for_libmysql
Voting ends in 2 weeks.
Kind regards,
Kamil
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
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
ally 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
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
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
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
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
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');
}
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
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
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
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
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"
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?
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
+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
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
It's WSL2
uname -r
5.4.72-microsoft-standard-WSL2
> 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
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
Development for 8.1 is already closed. You can only target this for 8.2
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
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
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
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
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
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
1 - 100 of 175 matches
Mail list logo
