>From: Anton Smirnov
>Date: Sun, 3 Mar 2024 at 19:56
>
>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:
rection, it makes more sense to emit a deprecation
notice
now and throw an exception starting in 9.0.
Regards,
Mel Dafert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 14 September 2022 21:39:36 CEST, "Tim Düsterhus" wrote:
>Hi
>
>On 9/13/22 19:58, Mel Dafert wrote:
>> - Deciding that `max_input_vars` is not relevant anymore and should be
>> handled by the likes of Apache and NGINX, thus changing the default to
>> `0` a
On 14 September 2022 16:44:33 CEST, Thomas Nunninger
wrote:
>Hi,
>
>> In summary, I believe this can only be solved inside of PHP itself, by
>> allowing to configure a way for `max_input_vars` to abort the request
>> instead of truncating the input.
>> The options I see feasible are:
>> - A
On 13.09.22 20:29, Jordan LeDoux wrote:
On Tue, Sep 13, 2022 at 10:59 AM Mel Dafert wrote:
(This happens in the legacy application I am working on, I do
not
see it changing anytime soon.)
All of these solutions would be available in some future version of
PHP. While your
that `max_input_vars` is not relevant anymore and should be
handled by the likes of Apache and NGINX, thus changing the default to
`0` and removing the setting
over a deprecation period.
I am leaning towards the first option, but would be open to either outcome.
Regards,
Mel Dafert
[1]:
https
On 16 June 2022 09:10:08 CEST, Pierrick Charron wrote:
> [...]
>- For consistency expose the new Curl URL API as functions mapped one to
>one to libcurl functions :
>
>function curl_url(?string $url = null): CurlUrl|false {}
>function curl_url_set(CurlUrl $url, int $part, string $content, int
>> In one application recently I actually had the string "false" (coming
>> from a form transmission) being passed to a boolean argument and leading
>> to true, which definitely was unintended.
>
>But "false" is a perfectly sensible thing to pass as a string in an
>API (as HTTP is a string based
On 7 May 2022 12:54:45 CEST, Craig Francis wrote:
>I will note that my RFC does not change NULL coercion (why I quoted the
>documentation), and I'm not against the other BC breaks where certain type
>coercions are clearly problematic.
>
>It was 8.1 which introduced this specific BC problem
>I see, so as long as there are no bool type hints for function parameters
>everything would be the same.
>
>This would lead to a minor asymmetry for
> $preserve = "yes";
> if ($preserve) # Silently working, true
> array_slice($array, $offset, preserve_keys:
On 8 April 2022 19:34:52 CEST, Craig Francis wrote:
>Hi,
>
>I've written a new draft RFC to address the NULL coercion problems:
>
>https://wiki.php.net/rfc/null_coercion_consistency
>
>This is due to the result of the Allow NULL quiz:
>
>https://quiz.craigfrancis.co.uk/
>
>14 votes for Fatal Type
>Hi,
>
>In PHP, you can write `$array['a']['b']['c'] ?? 'default';`. It works when
>either null or inexistant index is encountered at any depth of the expression.
>
>—Claude
You're right, I did not know that. Thank you.
That basically replaces the need for my proposal, then.
Regards,
Mel
--
On 27 February 2022 00:04:58 CET, Kamil Tekiela wrote:
>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
On 24 February 2022 09:47:39 CET, Go Kudo wrote:
>
>Hi
>
>RFC has been updated. Is this up to the required standard?
>https://wiki.php.net/rfc/rng_extension
>
>I acknowledge that the previous RFC may have been difficult to discuss. If
>the problem has been solved, I would like to make another
On 11 February 2022 07:26:45 CET, "Michał" wrote:
>Hi everyone.
>It's a known fact that nowadays most websites use at least UTF-8
>encoding. Unfortunately PHP itself has stopped a bit in the previous
>century. Is there any reason why the mbstring extension cannot be
>introduced to core in the
On 1 February 2022 17:06:59 CET, Stephen Reay wrote:
>
>The proposed API switches between terms `front`, `back`, `start` and `end` in
>comments - is there meant to be a conceptual difference between front/start
>and end/back ?
On a similar note, why are the methods for getting the first/last
Hello internals,
>register_operator(*, function (Foo $lhs, Bar $rhs): Foo { ...});
>register_operator(*, function (Bar $lhs, Foo $rhs): Foo { ...});
>register_operator(*, function (int $lhs, Foo $rhs): int { ...});
>
>But this just brings a new set of problems, including visibility issues
>(i.e.
On 16 November 2021 23:02:59 CET, Kamil Tekiela wrote:
>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
On 26 June 2021 02:39:52 CEST, Go Kudo wrote:
>Hello Internals.
>
>RFC has been reorganized for finalization.
>
>https://wiki.php.net/rfc/rng_extension
>
>The changes from the previous version are as follows:
>
>- Changed again to a class-based approach. The argument can be omitted, in
>which
>- `is_trusted()` - suggested by Moritz and separately by Mike, was the
>second option in the original vote, and was based on the idea that what is
>returned can be 'trusted' to be free from external code.
Another idea - `is_internal()`, since it is not external code, and internal
would be the
>I would prefer an improved syntax for creation of anonymous objects. This
>is something which I have been annoyed with, myself.I'd like to see a
>simple way of creating anonymous objects with typed properties.
Another advantage arrays currently have over anonymous objects is destructuring
-
if
Hi internals,
After the RFC to add IntlDatePatternGenerator () was accepted, it was brought
up that the duplication of
procedural and OO style was not necessarily/useful anymore.
This already has some (old) precedent - in 2012, UConverter was added to
ext/intl
>Right, for the purposes of this RFC, it's okay to just drop them if there
>are no objections. A general policy RFC may still be useful for future
>reference.
In that case, I will just go ahead and remove the procedural style from my
implementation (unless someone speaks up and objects).
I will
>Agreed with Nikita. There's no compelling reason to add double-API style
>anymore. It may take a second RFC to modify this one to remove those,
>technically, but I'd vote for it.
Should this new RFC then only apply to IntlDatePatternGenerator, or should it
also
clarify that future additions
>It's ... checks calendar ... the year 2021. Do we *really* need to add a
>procedural mirror APIs, especially with such auspicious function names as
>datepatterngenerator_get_best_pattern?
>
>I believe the procedural APIs are considered legacy APIs, and we are
>intentionally not adding them for
Hi Internals,
I am pleased to announce that this RFC has been accepted unanimously.
I have closed the vote.
Regards,
Mel
- Original Message -
From: "Mel Dafert"
To: "internals"
Sent: Friday, May 14, 2021 5:56:23 PM
Subject: [PHP-DEV] [VOTE] Add IntlDatePatternGen
Hi Internals,
I have opened the vote on https://wiki.php.net/rfc/intldatetimepatterngenerator.
I will close it on 2021-05-28.
For previous discussion see https://externals.io/message/113831 and
https://externals.io/message/114124.
Regards,
Mel
--
PHP Internals - PHP Runtime Development
I am planning to open the vote on this tomorrow, if there aren't any objections.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
>> This plaintext reply sent via Gmail web client. I don't know what Mel is
>> talking about either.
>>
>>
>Gmail's web client is what I normally use, and have never had an issue with
>it.
Sorry for being unclear - I meant the Gmail android app.
If the app does have an option for plaintext
On 10 May 2021 23:57:51 CEST, Christian Schneider wrote:
>No.
>Outlook is not modern.
While I agree with this (and I also agree with keeping bottom-posting), I feel
like we could make this easier
for new contributors by giving some examples of which clients to use and how to
configure them.
>For both points, I'd say "consistency wins by default." So if the other
>classes in that package already skip "Time" and use ::create() instead of a
>constructor, you should do the same as well unless there's a very good reason
>not to.
I have updated the RFC to use switch to the naming
> For both points, I'd say "consistency wins by default." So if the other
> classes in that package already skip "Time" and
> use ::create() instead of a constructor, you should do the same as well
> unless there's a very good reason not to.
The problem with ::create is that in the intl
Hi Internals,
I would like to propose an RFC
https://wiki.php.net/rfc/intldatetimepatterngenerator to add
IntlDateTimePatternGenerator
which exposes ICU's ability to flexibly create localized date/time formatting
patterns from a skeleton.
Previous discussion:
Hello,
I would like to request wiki karma to create an RFC for
IntlDateTimePatternGenerator (see https://github.com/php/php-src/pull/6771).
My wiki account name is deltragon.
Thanks,
Mel Dafert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https
ice versa).
PS: Sorry about the duplicate/badly formatted message - I am new to the concept
of mailing lists.
- Original Message -
From: "Máté Kocsis"
To: "Mel Dafert"
Cc: "internals"
Sent: Sunday, March 28, 2021 7:45:46 PM
Subject: Re: [PHP-DEV] Proposa
versa).
From: "Máté Kocsis"
To: "Mel Dafert"
Cc: "internals"
Sent: Sunday, March 28, 2021 7:45:46 PM
Subject: Re: [PHP-DEV] Proposal: add IntlDateTimePatternGenerator
Hi Mel,
Thank you very much for working on this! I was bitten by lack of this
functionality a
://github.com/php/php-src/pull/6771
I assume that this will require an RFC, in which case I request the karma to
create one. My wiki account is deltragon.
Regards,
Mel Dafert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
37 matches
Mail list logo
