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

[Christian Schneider]

Am 04.04.2024 um 08:29 schrieb Saki Takamachi :
> I added some examples, corrected incorrect explanations, etc. Now that the 
> specifications have been fairly finalized and the RFC has been clarified, I 
> would like everyone to check it out again.
> 
> https://wiki.php.net/rfc/support_object_type_in_bcmath

Looks very promising!

The default value for rounding is PHP_ROUND_TOWARD_ZERO. Is this because it is 
the same as the BCMath functions for consistency only or do you expect this to 
be the most used rounding mode?
I didn't find any discussion about this choice, sorry if I missed it.

Regards,
- Chris

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

[Christian Schneider]

Am 30.03.2024 um 16:35 schrieb Daniil Gentili :
>> That would break lots of tools as it requires extra dependencies so it is 
>> not something that would could in stable versions.
> Btw, I do not believe that "it would require end users to install autotools 
> and bison in order to compile PHP from tarballs" is valid reason to delay the 
> patching of a serious attack vector ASAP.

I agree with Jakub that removing configure would just shift the problem, not 
solve it, while at the same time puts a new burden on people compiling PHP from 
downloaded archives.

But my main question is: I fail to see the difference whether I plant my 
malicious code in configure, configure.ac or *.c: Someone has to review the 
changes and notice the problem. And we have to trust the RMs. What am I missing?

Regards,
- Chris

Re: [PHP-DEV] Idea: Implicit inheriting function argument & return type-hint

[Christian Schneider]

Am 09.03.2024 um 08:18 schrieb Marc :
> As the pseudo type `mixed` exists since PHP 8.0, which is already 
> out-of-date, I have the feeling it would be better to force people to 
> explicitly write `mixed` to widen the type of an overwritten function and let 
> "no type" inherit the argument and return type of the parent.
> 
> Example:
> 
> class A {
> public function typed(int $var): int { return $var; }
> public function untyped($var) { return $var; } // implicit mixed as no 
> overwrite
> }
> class B extends A {
> public function typed($var) { return $var; } // implicit int as inherited 
> from overwritten function
> }

This sounds like a bad idea to me as I cannot look at the function definition 
in class B and determine what the type of $var is.
On top of that: If the type of $var in A is changed then it would automatically 
also change in B. While this seems convenient it could also break B in subtle 
ways as the function suddenly gets different types than expected.

Regards,
- Chris

Re: [PHP-DEV] is this thing on?

[Christian Schneider]

Am 26.02.2024 um 14:25 schrieb Daniil Gentili :
> I really don't think that a modern discussion system can afford to randomly 
> loose messages: mailing lists should not be used in 2024.

Just because Gmail decided to tighten the rules about SPF/DKIM just now does 
not mean email is broken or loses messages on a regular basis.
Repeating it does not make it true, let's agree to disagree.

Regards,
- Chris

Re: [PHP-DEV] is this thing on?

[Christian Schneider]

Am 26.02.2024 um 10:56 schrieb Daniil Gentili :
>> gmail is failing to send emails to the list (hence why it has probably been 
>> a bit quite around here). Here is the error:
> +1, personally I would just switch to github issues and discussions, even 
> ignoring all the deliverability issues, I don't think using a mailing list is 
> a good idea for a modern programming language, seeking new contributors and 
> new ideas in 2024. 
> VCS was already moved to github after the recent hack of the php VCS, a lot 
> of technical internals-related discussion is already using exclusively github 
> issues and pull request discussions, I believe that the mailing list is 
> nothing more than a redundant relic of the past.

I very much disagree as I still prefer email to having discussions in issues or 
PRs. It is still the sweet spot for me with easy of use and feature support 
from a modern email client.

Issues and PRs are IMHO suited for bugs, feature requests and other code 
changes, not for discussions.

And no, I don't like discussion forums like reddit or Discord either. Writing 
to the amount of people following php internals should be done with some 
consideration and more social media type of platforms unfortunately - in my 
experience - tend to encourage noise.

Just my $.02,
- Chris

Re: [PHP-DEV] RFC Proposal - static modifier for classes

[Christian Schneider]

Am 20.11.2023 um 22:00 schrieb Lanre Waju :
> I will have to disagree with everything you said:

Side-note: This is IMHO not a good intro into a discussion ;-)

> I outlined what a static class would be: A class that cannot be instantiated 
> in which all members are implicitly static. We already have static members, 
> so please elaborate on the maintenance burden that adding static to a class 
> as that could help explain better, i mean what feature doesn't have technical 
> debt associated with it? The new JIT engine?

That is his point: The benefit has to outweigh the debt and for something like 
a class modifier this can lead to a matrix of possible combinations, 
complication things down the line.

>>> 3. It is entirely opt-in. If you hold reservations about using static
>>> classes, you can simply choose not to use them.
>> This is a spurious and disingenuous argument, even if it gets trotted out 
>> frequently on many RFCs.  I'm not picking on you in particular here, but 
>> it's a bad argument to use, period, 99% of the time, no matter who is saying 
>> it.
> If you insist, Mr. Larry.

I’m with Larry there: Being able to just ignore new features is sometimes 
helpful (i.e. avoids the discussion about BC) but not a strong argument on 
*why* something should be added. This lists very much also cares about the 
implementation and maintenance costs as well as the simplicity/consistency of 
PHP. Being opt-in just does not carry much weight in that context.

>> Similarly, if we add a static marker to classes, that means all future 
>> improvements to classes need to consider "but what if the class is static?"  
>> Eg, there was discussion a while back about `data` classes.  What happens if 
>> you have a `static data class`?  Is that a syntax error?  Does it work?  If 
>> it works, what does "work" mean?  What about sealed classes?  Can you have a 
>> sealed static class?  What would that mean?  Those are questions that would 
>> need to be answered, because this feature exists.
> Either i'm in an alternate reality where the data classes and sealed classes 
> rfcs passed, or I've just been straw-manned. Either way, is it really that 
> difficult to decide on as a community what a static data class implies? We 
> have already established that a static class means all the members are 
> static, but i can try to dumb it down for you if need be.

Being a long time member of this list (even though with only very occasional 
contributions to the source code) I have to say: There is a wide range of 
experience in both language design and implementation (for both PHP and in 
general) represented here, some members coming from an almost exclusively 
language-user point of view. And that is a great thing!
But I’d recommend to not underestimate the knowledge contributed by people who 
have been involved for some time and possibly even learned from previous 
mistakes :-)

Having said all that I just wanted to add that I would most probably vote 
against static classes even though we use class-as-a-namespace here sometimes 
but still don’t feel the need for it to being a language feature for the 
reasons mentioned by Rowan and Larry.

Regards,
- Chris

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

Re: [PHP-DEV] Custom object equality

[Christian Schneider]

Am 18.10.2023 um 18:42 schrieb Larry Garfield :
> So the real question is: Would anyone who voted No on operator overloading 
> before vote Yes on it if it used ~=,  ~>, ~+, etc. instead?

I confess that I'm not a fan of operator overloading for a language like PHP 
but introducing new operators on top of making them overloadable seems a bad 
idea. Operators have the problem of being hard to look up and prefixing them 
with ~ feels like the worst of both worlds.

Regards,
- Chris

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

Re: [PHP-DEV] Change default method of disabling JIT for PHP 8.4

[Christian Schneider]

Am 18.10.2023 um 10:42 schrieb Daniil Gentili :
> This is precisely why I'm planning to submit the RFC to make the change in 
> PHP 8.4, which is when the new JIT will be introduced.

Ah, I missed that part, my bad. I'd suggest mentioning this in the RFC.
I also went back Dmitry's RFC and saw that no change on default ini settings is 
planned from his side.

Regards,
- Chris

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

Re: [PHP-DEV] Deprecate posix_times

[Christian Schneider]

Am 17.10.2023 um 19:39 schrieb Daniil Gentili :
> I would like to submit an RFC (and related PR) to deprecate posix_times for 
> PHP 8.4, removing it for PHP 9.

My question here would be: Is there sufficient reason to remove this function 
and introduce a BC break, i.e. is the implementation code hard to maintain or 
does the function cause security issues?

Unless that is the case I'd leave it unchanged and just add a note to the 
documentation that people might want to consider using getrusage() instead.

Regards,
- Chris

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

Re: [PHP-DEV] Change default method of disabling JIT for PHP 8.4

[Christian Schneider]

Am 17.10.2023 um 19:46 schrieb Daniil Gentili :
> I would like to submit an RFC and PR to change a few INI defaults for 
> opcache, changing how JIT is disabled by default.
> 
> Currently, JIT is disabled by default using the |opcache.jit_buffer_size=0| 
> default, instead of |opcache.jit=0|.
> 
> I would like to change these defaults to:
> 
> - opcache.jit=off
> - opcache.jit_buffer_size=64m (taken from 
> https://github.com/php/php-src/pull/12425/files, any smaller multiple of 2 
> causes the buffer to fill up when running moderately sized projects like 
> Psalm or PHPStan).

I understand your point but it might unexpectedly switch behavior for people 
just setting jit_buffer_size and expecting this to turn JIT on.
While (in the light of a new upcoming JIT)  this might not be a big deal it is 
also not clear if it is worth it.
Maybe the settings can be overhauled once the new JIT is introduced (which 
might have different settings anyway).

Regards,
- Chris

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

Re: [PHP-DEV] Better name for method Randomizer::nextFloat()

[Christian Schneider]

Am 15.10.2023 um 19:24 schrieb Tim Düsterhus :
> Making getFloat(float $min = 0.0, float $max = 1.0, IntervalBoundary 
> $boundary = IntervalBoundary::ClosedOpen) would seemingly make it legal to 
> call ->getFloat(0.5), which I consider to be worse than nextFloat().

While I understand that you find getFloat(0.5) undesirable I would not consider 
it illegal, e.g. getFloat(max:5).
Additionally I would consider getInt(max:100) to be a very valid usage too.

> Side note: The implementation of nextFloat() is much more efficient than that 
> of getFloat(0.0, 1.0) and the output will differ even for the same seeded 
> engine. The domain of legal return values is identical.

This sounds like an implementation detail as I'm pretty sure you could switch 
to that fast path easily enough if neither of the arguments were given.

Side-note: The case of nextInt() is a bit trickier and strikes me as a bit of a 
weird API and I'd consider dropping it too: Having the max value depend on the 
Randomizer engine makes the generated values unstable in regards to switch the 
Engine. And if I read the documentation correctly then it only generates 32 bit 
values (or should it be 31 bits as it returns positive values only?). I think 
it would be clearer to require the Engine to provide at least 4 bytes and then 
specify the default max value of getInt() to be 2^31, optionally overridable 
with something up to PHP_INT_MAX.

So in summary I'd support both adding default values to getInt()/getFloat() as 
well as dropping nextFloat() in favor of getFloat() (and possible nextInt() 
with getInt()). 

Regards,
- Chris

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

Re: [PHP-DEV] [RFC] [VOTE] mb_str_pad

[Christian Schneider]

Am 05.06.2023 um 19:59 schrieb Niels Dossche :
> I'm opening the vote now on my proposal to include mb_str_pad() into PHP 8.3.
> RFC link: https://wiki.php.net/rfc/mb_str_pad

I voted "No" because I think it should be grapheme_str_pad instead and I'd like 
to avoid having both the mb_ and grapheme_ versions which unnecessarily 
confuses users.

I guess I should have spoken up before but I couldn't think of a use case for 
padding characters instead of graphemes. Or am I missing something?

- Chris

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

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

[Christian Schneider]

Am 12.04.2023 um 15:52 schrieb Alex Wells :
> PHP currently uses internals@lists.php.net for communication. That includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
> 
> While emailing definitely works, it's not the best UX out there.

…

> What are your thoughts?

Also see the recent thread at
https://externals.io/message/119757#119786
where there are some thoughts on the UX points (e.g. editing of messages).

Regards,
- Chris

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

Re: [PHP-DEV] Broken Wiki Registraiton (was: [IDEA] allow extending enum)

[Christian Schneider]

Am 30.03.2023 um 10:50 schrieb Lynn :
> That said, mailing lists are ancient and in my opinion a horrible way of 
> doing things.

Mailing lists have been around for a long time, yes, but it also means the way 
we use it for larger scale communication has been refined over time. Please 
consider that this process is based on a lot of experience.

> I've had my fair share of issues to sign up initially, there's a weird 
> etiquette of how you have to structure your replies

Once you familiarized yourself with the notion of giving enough context to your 
reply parts (but not too much) it becomes a very valuable way of keeping 
communication efficient.
The main point is that 1 person is writing a reply but 100s to 1000s have to 
read it and they do not have  the same mental context as the writer.
So spending this extra effort to minimize the effort of the reader is well 
worth it.

> , and most importantly you have to remind yourself.every time to press "reply 
> all".

As it is sufficient to just reply to the mailing list this could technically be 
changed by adding a Reply-To. The downside would be that it makes private 
replies harder and the occasional slip-up could send a private reply to the 
list instead.
IMHO private replies should be kept to a minimum so I think (re-)considering 
adding a Reply-To might be worth it.

> There are also issues with messages ending up in junk-mail or caught by 
> spam-filters, and you heavily depend on your
> mail client to properly group messages so you can actually digest them in a 
> conversational form.

Threading emails has been part of mail clients for 20 years, I'm puzzled that 
people still consider this to be an issue.
Mail filters also allow to automatically separate into folders, if one wishes 
so.

> Email is also lacking edit buttons

This is actually an important feature! It forces the writer to be more careful 
with replies which in turn safes time for the 100s of readers.
It also means that I don't miss edits or have to go back to edited messages and 
guess what has changed.
Editing messages just doesn't scale well with large recipient groups IMHO.

> and integrated code blocks like we're used to with github (or markdown in 
> general).

I don't think it is hard to format example code in a way that they are readable 
in an email.
Again: It is a little bit of extra work for the writer but this tends to lead 
to simpler code examples for the reader.

Regards,
- Chris

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

Re: [PHP-DEV] [IDEA] allow extending enum

[Christian Schneider]

Am 29.03.2023 um 11:55 schrieb Tim Düsterhus :
> On 3/29/23 11:42, Sebastian Bergmann wrote:
>> Am 29.03.2023 um 11:31 schrieb Rokas Šleinius:
>>> I wouldn't say removing the final attribute from enums actually "breaks" 
>>> any functionality.
>> I am with Marco on this: removing the "finality" from enum would be a
>> major backward compatiblity break as it breaks a fundamental assumption
>> about enums.
> 
> And to give a specific example from PHP 8.3: As part of the Randomizer 
> additions RFC (https://wiki.php.net/rfc/randomizer_additions), PHP 8.3 got 
> its first "natively included" enum (\Random\IntervalBoundary). This enum 
> works together with the new Randomizer::getFloat() method to specify if the 
> given min and max value may be returned or not.
> 
> The Randomizer::getFloat() method internally includes switch statement that 
> chooses the implementation based on the IntervalBoundary value given.
> 
> If a user would be able to extend the IntervalBoundary enum, the method would 
> not be able to make sense of it.
> 
> The IntervalBoundary enum completely enumerates all four possible 
> combinations for the two possible states for each of the two boundaries (2*2 
> = 4). By definition there is no other valid value.

I do understand the reason behind making Enums final and your example 
illustrates the point very well.

I still have a question I already asked in a different context: If there ever 
is the need to add a case to an Enum, was there any thought put into making 
this possible? Or is this categorically ruled out when using Enums?

Let’s look at a very, very hypothetical example: Imagine a Randomizer is much, 
much slower for certain boundaries and it is decided that some programs do not 
care about Closed/Open but instead care more about speed. So they would want to 
use something like IntervalBoundary::Fastest.

As far as I understand such an addition would *never* be possible, right? This 
means people defining Enums have to be very very certain that no one will ever 
want another value, right?

Regards,
- Chris

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

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

[Christian Schneider]

Am 28.03.2023 um 14:42 schrieb G. P. B. :
> On Tue, 28 Mar 2023 at 08:19, Christian Schneider  
> wrote:
>> There are two cases I would handle differently:
>> - I'm not sure why a negative step for $start > $end is considered wrong, I 
>> consider range(10, 0, -2) at least as logical/readable as using a positive 
>> decrement of 2. Not requiring a sign for steps seems weirder to me but 
>> that's something we cannot change. *BUT* if it is the result of a 
>> calculation it seems wrong to require an abs() around it. I do see the 
>> reason for a warning/error when $start < $end and $step < 0.
>> 
> Considering the only other programming language that I know of that has a 
> range() function that accepts a step argument is Python, and its behaviour is 
> IMHO worse.
> For increasing ranges it requires a positive step, and if not just generates 
> an empty range. For decreasing ranges it requires a negative step, and if not 
> just generates an empty range (this applies even if using the default step 
> value of 1 which is bonkers).
> 
> Making it a requirement to pass a negative step is definitely out of the 
> question.
> Making it okay to use negative steps *only* for decreasing ranges could be 
> sensible, but we check for the step parameter way before we look into the 
> boundary values because those are different for int, float and string 
> boundaries.
> Moreover, I personally find it weirder to require a sign for negative steps 
> as for me a step is something that *must* be positive

I quickly checked our own codebase and there is indeed one instance of
range($last, 0, -1)
which was not written by me so there is at least one more person who found this 
logical ;-)

>>  - Values of '' or null in integer context (e.g. range(null, 10, 2)) should 
>> IMHO emit a warning first, not directly be changed to a TypeError. The usual 
>> BC / migration concern :-)
> 
> Trying to figure out if an empty string was used with another string boundary 
> is tedious, as this information needs to somehow get carried around.
> A previous iteration of the PR used to convert empty strings to 0 with a 
> warning, but considering the analysis I decide to just make this a ValueError 
> as it doesn't seem that empty strings are actually used in practice.
> But this is an easy revert, and I'm not really bound to this decision.

Even though this might be a bit cumbersome at the moment I think this would be 
an important transition step as currently
range('', 10, 2);
returns the (somewhat) expected result of 0, 2, 4, 6, 8, 10 so I'd be in favor 
of first giving a warning and then changing it to a ValueError.

- Chris

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

Re: [PHP-DEV] RFC [Discussion]: Make unserialize() emit a warning for trailing bytes

[Christian Schneider]

Am 28.03.2023 um 00:22 schrieb Larry Garfield :
> On Mon, Mar 27, 2023, at 2:12 PM, Mel Dafert wrote:
>> On 27 March 2023 20:20:58 CEST, "Michał Marcin Brzuchalski" 
>>  wrote:
>>> Personally, I'd like the unserialize to throw an exception if trailing 
>>> bytes are detected.
>>> If not by default then with the use of the option passed to unserialize 
>>> function.
>> 
>> If that's the desired direction, it makes more sense to emit a 
>> deprecation notice now and throw an exception starting in 9.0.
> 
> I would also favor throwing an exception.  This is a security vector being 
> closed, and that should be closed *hard*.  Warnings tend to show up where 
> they're not useful (dev) and get not noticed where they are (prod).  Go all 
> the way to an exception here.

I'm not sure why you say this because our set up is the opposite: On dev the 
warnings are on screen (and could potentially be missed), on production they 
generate an alert so they are much harder to miss. That's a set up I would 
recommend, it has worked well for us in maintaining quite an old code base 
while migrating it to the current PHP version.

> I'm flexible on if that happens in 8.3 or 9.  Maybe warning now, with 
> exception in 9?  I don't know if that's better from a BC POV, but it should 
> end up as an exception.

I'm generally in favor of going through a warning phase before switching to an 
exception but if the people here consider this a real security issue I wouldn't 
rally against an exception.

Regards,
- Chris

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

Re: [PHP-DEV] [RFC] Define proper semantics for range() function

[Christian Schneider]

Am 28.03.2023 um 00:36 schrieb G. P. B. :
> I therefore propose the "Define proper semantics for range() function" RFC
> to address the unintuitive behaviour that sees no usage and/or hide bugs:
> https://wiki.php.net/rfc/proper-range-semantics
> 
> The change propose to throw TypeErrors and ValueErrors for case where I
> couldn't find occurrences in the wild and hide bugs, and emit some
> E_WARNINGs for cases that are hard to detect via static analysis.

I think it makes sense to clean up the range() function, thanks!

There are two cases I would handle differently:
- I'm not sure why a negative step for $start > $end is considered wrong, I 
consider range(10, 0, -2) at least as logical/readable as using a positive 
decrement of 2. Not requiring a sign for steps seems weirder to me but that's 
something we cannot change. *BUT* if it is the result of a calculation it seems 
wrong to require an abs() around it. I do see the reason for a warning/error 
when $start < $end and $step < 0.
- Values of '' or null in integer context (e.g. range(null, 10, 2)) should IMHO 
emit a warning first, not directly be changed to a TypeError. The usual BC / 
migration concern :-)

Regards,
- Chris

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

Re: [PHP-DEV] First-class callable partial application

[Christian Schneider]

Am 10.03.2023 um 20:04 schrieb Eugene Sidelnyk :
> Another simplified example:
> 
> ```
> // partial application
> foo(bar(1, ...));

While it is not as concise as your version I think the work-around with short 
arrow functions works ok unless your code is full of partial applications:
foo(fn(...$a) =>  bar(1, ...$a));

Regards,
- Chris

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

Re: [PHP-DEV] PHP code refactoring (was: include cleanup)

[Christian Schneider]

Am 01.03.2023 um 01:13 schrieb Bob Weinand :
> In this case, while the primary concern of the RFC was rejected, I think it's 
> pretty clear, that there was a supermajority for something specific.

I didn't vote on this RFC but I have to disagree with you and Max here: My 
understanding of such a voting process is that the secondary votes are 
dependent on the acceptance of the first one.

This means I would interpret it as 'if and only if "Should #include directives 
be cleaned up?" Is accepted then I'm voting yes for "Is it allowed to split a 
large header to reduce dependencies"'.

I can't know whether the people voting here meant it that way or not, I'm just 
saying that taking the second vote out of context seems problematic to me. 
Reminds me a bit of looking at the numbers of an A/B test when the precondition 
"is the result significant" is false.

Regards,
- Chris

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

Re: [PHP-DEV] PHP code refactoring (was: include cleanup)

[Christian Schneider]

Am 28.02.2023 um 22:04 schrieb Max Kellermann :
> On 2023/02/28 21:16, Dmitry Stogov  wrote:
>> Recently we voted for inluce cleanup RFC
>> https://wiki.php.net/rfc/include_cleanup and it was declined.
> 
> Which specific commits do you wish to revert?  Is this about include
> cleanups (none of which were merged) or about header splitting (which
> a supermajority voted for) or about other kinds of code refactoring
> (which was not voted on)?

You keep saying that people voted yes on the secondary vote (clarifications on 
how to clean up).
Just to clarify: This is irrelevant as the primary vote was declined.

> My opinion is: if a patch improves a piece of code, it should be
> merged.  Of course, whether something is an improvement is debatable;
> but postponing that decision is pointless and harmful.

As far as I can see there seems to be a disagreement whether it is an 
improvement, which to me sounds like there must be more discussion. Which means 
the decision has to be postponed, no?

I second Dmitry's request to do things in a managed way.
What exactly caused the disruption I'm not sure and it is not about blaming 
someone but finding a workable solution.

Regards,
- Chris

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

Re: [PHP-DEV] [RFC] [Vote] Readonly amendments

[Christian Schneider]

Am 24.01.2023 um 09:55 schrieb Máté Kocsis :
> We've just opened the vote for the "Readonly amendments" RFC, which is
> going to be open for 2 weeks (until 2023-02-07).
> 
> Link: https://wiki.php.net/rfc/readonly_amendments
> Discussion: https://externals.io/message/119007

I like the idea of more power to developers (even if they can shoot themselves 
in the foot), so I'm supporting this RFC.

While reading the example "Here is an example of a non-readonly child class 
that tracks the number of times a method has been called ... Such constructs 
are commonly used in e.g. mock classes ..." I was wondering why the same 
argument isn't applicable to most classes recently proposed as 'final', e.g. 
Text or Dequeue.

I know that there is the school of thought that "inheritance is bad" which 
discourages extending existing classes but I'm still not fully convinced 
something like benchmarking, logging or mocking are not valid applications of 
inheritance. Discouraging inheritance is one thing, disallowing another.

Maybe this needs to go to a separate thread but this RFC made me aware of this 
issue (and the different views people have about where PHP should go) again.

Regards,
- Chris

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

Re: [PHP-DEV] Measuring Proposal Reaction

[Christian Schneider]

> Am 18.01.2023 um 23:29 schrieb Larry Garfield :
> On Tue, Jan 17, 2023, at 1:25 PM, Jesse G. Donat wrote:
>> I'm looking to measure reaction to a proposal.
>> 
>> My proposal is to have the STDOUT and STDERR global constants always
>> defined rather than just when running via CLI.
> 
> Does anyone know why those constants are left out?  Given that the 
> functionality can still be used, as noted...

I could imagine old code checking if STDOUT/STDERR is defined to determine if 
they are running in CLI.
While there are now other ways to do it it would probably be a minor BC break 
to now defined them.

Turning the question around: As there is already a way of accessing 
STDOUT/STDERR with php://, should we introduce a BC break?

Side-note: If we decide to now define the constant for all SAPIs, should 
defined('STDOUT') etc. throw some sort of warning so code checking for it can 
be found more easily?

- Chris

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

Re: [PHP-DEV] [RFC] Add SameSite cookie attribute parameter

[Christian Schneider]

Am 18.01.2023 um 16:26 schrieb Claude Pache :
>> Le 18 janv. 2023 à 16:20, Derick Rethans  a écrit :
>> 
>> if (version_compare(phpversion(), "8.4.0", ">")) {
>> setcookie("test", "value", samesite: SameSite::Stricter);
>> } else {
>> setcookie("test", "value", samesite: SameSite::Strict);
>> }
> 
> Or even, replace `version_compare(...)` with `SameSite::tryFrom(...) !== 
> null`:
> setcookie("test", "value", samesite: SameSite::tryFrom('Stricter') ?? 
> SameSite::Strict);

Thanks for your replies, I like the second option as it is a feature instead of 
a version check.

Now my only itch is that the support for SameSite=Stricter is actually 
depending on the browser, not the server so assuming all browser are already 
supporting this new mode I should not send a less strict mode just because I'm 
using an old PHP version. This is currently possible since setcookie() does not 
validate the content of the samesite options.
But as this is somewhat of a special case (most function options do not depend 
on something external) and you seem to be confident that the list of SameSite 
options will not change any time soon I'll shut up now :-)

Regards,
- Chris

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

Re: [PHP-DEV] [RFC] Add SameSite cookie attribute parameter

[Christian Schneider]

Am 17.01.2023 um 15:59 schrieb G. P. B. :
> Side-Note: Isn't SameSite a very generic name in the global namespace? I'm 
> not sure what the PHP policy is here.
> 
> AFAIK the global namespace is "owned" by PHP so that shouldn't be an issue 
> per the usual policy.

In a quick check I could not find any other Enums defined in the core. Would 
this be the first one?

I guess I was comparing it to constants where in most cases the constant name 
reflects where it is used, e.g. STR_PAD_LEFT and I was therefore wondering 
whether the name SameSite should somehow contain cookie in one form or another. 
Or is this frowned upon for Enums?

> Are there any Enums in core PHP APIs where new values could be added in the 
> future and how is the plan for code supporting multiple PHP version there? 
> This was just something which crossed my mind when thinking about APIs with 
> Enums. This is not really related to this RFC so I understand if you want to 
> ignore this part :-)
> 
> I might be again misunderstanding, but one cannot extend an enum as they are 
> final classes under the hood.
> Currently, the only other native enum is the one that was added with the 
> Randomizer Additions RFC [1] so this topic hasn't come up yet as the enum for 
> ext-random is definetely complete.

I'm talking about adding new values in later PHP versions, let's for example 
assume they would add a SameSite mode "Stricter" and PHP wants to support that.
How would one write code to use "Stricter" in code meant to work for both old 
and new PHP versions?

- Chris

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

Re: [PHP-DEV] [RFC] Add SameSite cookie attribute parameter

[Christian Schneider]

Am 16.01.2023 um 14:39 schrieb G. P. B. :
> On Sun, 15 Jan 2023 at 20:58, Christian Schneider  
> wrote:
> Some comments:
> - I am not convinced that we should introduce a third way of providing 
> parameters to setcookie(). I don't think this function is used often enough 
> in common code to add yet another iteration of the API. Assuming there is 1 
> to 2 places in your framework using this I don't think many bugs will go 
> unnoticed. Adding a warning to illegal 'samesite' values in $options would 
> IMHO be enough if stricter checking is wished for.
> 
> How is this providing a third way of providing parameters to setcookie()? As 
> it is, if I want to use named arguments and the typed parameters, I cannot 
> set the SameSite attribute.
> I've heard multiple people waste time due to a SameSite bug because they made 
> a typo, and it took them way too long to figure out the issue as they thought 
> they had a server configuration problem.
> Adding a warning for invalid values is effectively turning that option into 
> an Enum, which at this point one might as well have a proper Enum.

Maybe third API was misleading, what I mean is that we had the (old) way of 
positional arguments for options which did not include something like samesite 
and the (new) way with the options array. So I would assume most code was 
migrated to $options.
Now you are suggesting of updating the old API with an additional positional 
argument which would mean changing the array-form back to positional.
Is your plan to deprecate the $options-API at some point in the future? Having 
two APIs offering the same functionality seems a bit confusing to me.

Alternatively the 'samesite' option in $options could accept SameSite::Lax. 
This would accomplish (almost) the same with a smaller change. Disclosure: I 
like arrays for options as they allow for array addition etc. Something similar 
can be done with ...$options, true :-)

Side-Note: Isn't SameSite a very generic name in the global namespace? I'm not 
sure what the PHP policy is here.

>   - I don't like the camelCase of $sameSite as this is different from all the 
> other parameters, e.g. $expires_or_options (yes, this is a pseudo-parameter 
> name, I know) and $httponly. Looking at a couple of functions in the standard 
> PHP set I didn't see any $camelCase.
> 
> ACK, it should probably be in snake case and be $same_site

Looking at $httponly I would have expected $samesite.

>   - A more generic question: How are Enums handled concerning future 
> additions of values vs. BC compatibility? What is the migration plan there if 
> one wants to support both old and new PHP versions?
> 
> The parameter is optional, so I don't understand what migration plan you need?
> If in the, unlikely, event that a new value is added this should be added as 
> a case in the enum in the next minor version of PHP.
> In the, again unlikely, event that a value is deprecated, the corresponding 
> enum case should also be deprecated following the normal PHP deprecation 
> process.
> 
> I only decided to make this an enum because I deem it very unlikely for a new 
> valid attribute value to be introduced, the new IETF RFC clarifies and amends 
> the behaviour of the 3 valid attribute values that have always been the same 
> since 2016.

I was talking about extending Enums, not the parameter and not SameSite 
specifically.
Are there any Enums in core PHP APIs where new values could be added in the 
future and how is the plan for code supporting multiple PHP version there? This 
was just something which crossed my mind when thinking about APIs with Enums. 
This is not really related to this RFC so I understand if you want to ignore 
this part :-)

Regards,
- Chris

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

Re: [PHP-DEV] [RFC] Add SameSite cookie attribute parameter

[Christian Schneider]

Am 14.01.2023 um 16:14 schrieb G. P. B. :
> I would like to start the discussion about the Add SameSite cookie
> attribute parameter RFC:
> https://wiki.php.net/rfc/same-site-parameter
> 
> This proposes to add an optional same site parameter to the setrawcooki(),
> setcookie() and session_set_cookie_params() that takes a a value a new
> SameSite enum:
> 
> enum SameSite {
>case None;
>case Lax;
>case Strict;}


Some comments:
- I am not convinced that we should introduce a third way of providing 
parameters to setcookie(). I don't think this function is used often enough in 
common code to add yet another iteration of the API. Assuming there is 1 to 2 
places in your framework using this I don't think many bugs will go unnoticed. 
Adding a warning to illegal 'samesite' values in $options would IMHO be enough 
if stricter checking is wished for.
- I don't like the camelCase of $sameSite as this is different from all the 
other parameters, e.g. $expires_or_options (yes, this is a pseudo-parameter 
name, I know) and $httponly. Looking at a couple of functions in the standard 
PHP set I didn't see any $camelCase.
- A more generic question: How are Enums handled concerning future additions of 
values vs. BC compatibility? What is the migration plan there if one wants to 
support both old and new PHP versions?

Regards,
- Chris

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

[PHP-DEV] Re: Adding strtotime change to migration document

[Christian Schneider]

Am 11.01.2023 um 17:09 schrieb Christoph M. Becker :
> On 11.01.2023 at 15:19, Christian Schneider wrote:
> 
>> Am 11.01.2023 um 15:04 schrieb Christoph M. Becker :
>>> On 11.01.2023 at 14:07, Christian Schneider wrote:
>>> 
>>>> While migrating to PHP 8.2 we noticed the change in strtotime.
>>>> PHP <= 8.1 supported "today +- 3 days" etc. but the support for multiple 
>>>> sign characters (++, --, -+, +-) has been removed in 8.2:
>>>> https://3v4l.org/mHa3t
>>>> 
>>>> This was discussed at
>>>> https://github.com/php/php-src/issues/9950#issuecomment-1314101723
>>>> 
>>>> I understand the reasoning to remove support even though I liked the 
>>>> flexibility but as this is a small BC break I was wondering if it should 
>>>> be added to the migration document for 8.2.
>>> 
>>> Given that PHP itself has no problems with this
>>> (<https://3v4l.org/8WBEj>), I think a changelog entry is appropriate.
>>> Maybe you want to provide a respective PR?
>> 
>> I'm not familiar with the changelog / migration document handling but my 
>> preferred place would be a line in the migration document so people checking 
>> what they have to look out for hopefully see it. I don't think people read 
>> the full changelogs.
> 
> Documented as
> <https://github.com/php/doc-en/commit/cf220d0944b207510abb5e3c7c262140b8ac082c>.

Two little comments:
- It not only concerns a plus sign after a minus sign but all sign combinations 
++, --, +- and -+
- It also concerns strtotime(), I think this could be mentioned too

Regards,
- Chris

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

[PHP-DEV] Re: Adding strtotime change to migration document

[Christian Schneider]

Am 11.01.2023 um 15:04 schrieb Christoph M. Becker :
> On 11.01.2023 at 14:07, Christian Schneider wrote:
> 
>> While migrating to PHP 8.2 we noticed the change in strtotime.
>> PHP <= 8.1 supported "today +- 3 days" etc. but the support for multiple 
>> sign characters (++, --, -+, +-) has been removed in 8.2:
>> https://3v4l.org/mHa3t
>> 
>> This was discussed at
>> https://github.com/php/php-src/issues/9950#issuecomment-1314101723
>> 
>> I understand the reasoning to remove support even though I liked the 
>> flexibility but as this is a small BC break I was wondering if it should be 
>> added to the migration document for 8.2.
> 
> Given that PHP itself has no problems with this
> (<https://3v4l.org/8WBEj>), I think a changelog entry is appropriate.
> Maybe you want to provide a respective PR?

I'm not familiar with the changelog / migration document handling but my 
preferred place would be a line in the migration document so people checking 
what they have to look out for hopefully see it. I don't think people read the 
full changelogs.

- Chris

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

[PHP-DEV] Adding strtotime change to migration document

[Christian Schneider]

While migrating to PHP 8.2 we noticed the change in strtotime.
PHP <= 8.1 supported "today +- 3 days" etc. but the support for multiple sign 
characters (++, --, -+, +-) has been removed in 8.2:
https://3v4l.org/mHa3t

This was discussed at
https://github.com/php/php-src/issues/9950#issuecomment-1314101723

I understand the reasoning to remove support even though I liked the 
flexibility but as this is a small BC break I was wondering if it should be 
added to the migration document for 8.2.

Regards,
- Chris

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

Re: [PHP-DEV] [RFC] [Discussion] SQLite3: remove warnings, move to exceptions

[Christian Schneider]

Am 24.10.2022 um 04:56 schrieb BohwaZ :
> I am proposing that the SQLite3 extension stops using warnings for
> errors and instead throws exceptions by default:
> 
> https://wiki.php.net/rfc/sqlite3_exceptions
> 
> Whether we just deprecate warnings first and default to exceptions, and
> then remove warnings altogether in a later version, or just disable
> warnings directly, is probably the important part of the RFC.
> 
> My personal point of view is that modern code probably already have
> enabled exceptions in the class, or is transforming warnings into
> exceptions using an error handler.
> 
> If not, it's relatively easy to set a exception handler to dismiss the
> new exceptions if you don't want to see them.
> 
> So going throught depreciation might not be necessary, but it's open
> for discussion.

To no surprise for anyone reading this list I'm going to strongly advocate for 
going through a deprecation phase to ease migration of code.
As often the code changes needed might not be big but you still have to a) 
notice all the necessary changes (the SQLite exceptions might just be one of 
many changes in the new PHP version) and b) adapting the code should be 
decoupled from the PHP upgrade. Both of these goals are IMHO well handled by a 
deprecation phase.

Regards,
- Chris

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

Re: [PHP-DEV] Experimental features

[Christian Schneider]

Am 11.10.2022 um 07:09 schrieb MKS Archive :
>> On Oct 10, 2022, at 8:04 PM, David Gebler  wrote:
>> 
>> This is what's bothering me. Either these "experimental" features have
>> passed RFC and will be part of the language, as you've said above, or
>> they're actually experimental i.e. not finalized and implementing behaviour
>> and syntax which may be subject to change or even dropped entirely
>> depending on the feedback cycle. 
> 
> If they are not experimental and their usage is finalized, then they are 
> in-fact approved and they would be absolutely no different from the existing 
> RFCs today.
> 
> You cannot have experimental features unless those features have the 
> potential to not be included in the future language and/or those features 
> have the potential to be improved before they are finalized. Otherwise, 
> what's the point?

We seem to have two different views on experimental feature here: You are 
saying they could get removed again while others stated it is for stuff which 
will definitely end up in stable when the next major release is done.

IMHO there needs to be a consensus about this before we can continue the 
discussion, otherwise we will go around in circles.

>> Using the trivial json_validate() example (although as others have said, a
>> simple new function is probably a bad example), 
> 
> (As an aside, I disagree that a new function would be a bad example. I think 
> it would be a good use-case for experimental features because of how 
> decoupled it would be from the rest of the language, and it would help to see 
> if a lot of people use the function before committing to including it.)

That's another thing where we need to find an agreement first: Are we talking 
new, isolated functions or are we possibly also talking about core new language 
features (i.e. new syntax / semantics)?

The work for maintenance by core developers could be much higher if it is not 
limited to new functions.
This is IMHO an important aspect as we do not want to make life even harder for 
the core team.

Hot take: If it is only about new functions then we don't need anything in the 
core, just create an \Experimental package with poyfills and you're done ;-)

>> If it's the former, the library can just check if PHP >= 8.3 and fall back
>> to userland implementation / polyfill for earlier versions. This is just
>> what we have now, where approved new features are part of a versioned
>> release.
> 
> Not all potentially useful functions can reasonably be implemented in 
> userland PHP.

... but almost all of them can.

I'd go as far as saying that while emulating json_validate() using 
json_decode()  is slower and uses more memory it still is a valid polyfill. It 
is IMHO easy enough to develop with a higher memory limit and performance is 
not that critical for development either.

And unless you want to ship experimental code to production (which you 
shouldn't) you will have to wait for the next major PHP release anyway.

- Chris

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

Re: [PHP-DEV] Experimental features

[Christian Schneider]

Am 06.10.2022 um 23:40 schrieb David Rodrigues :
> But keep in mind that these features are already intended for PHP, and it
> is not a "feature test" or suggestion. The voting process is mandatory and
> the feature must already be set to "accepted".

Just so I understand what you are saying: You would only add things to 
experimental where an RFC for it has been accepted?
What you basically want to do is to introduce such features into the current 
stable branch instead of the upcoming one, right?

> However, we need to separate an experimental feature into stages, much like
> Node does, so these are my suggestions:

[...]

> 2. Open experimental: the feature has already been state internally by
> "adventurous users" and can already be used without php.ini configurations,
> however, its use in code still needs experimental markers (eg.
> experimental_json_validate() or declare(experimental_*)). BC is unlikely to
> happen unless the feature has issues that need to be resolved before an
> official release. Removing the feature is suggested not to happen, with the
> exception of very serious and irreparable issues.

One side-note here: I would strongly advise not to use an experimental_ prefix 
or package for functions because it would be a PITA to make code compatible 
with different versions, one where the function has the experimental_ prefix / 
package and one where it doesn't.

But now to my main point: You are talking about the most simple and isolated 
case, a new function.
Your model may work fine with that but as soon as we are talking something like 
a syntax change we have some additional problems:
- Enabling it with a prefix obviously does not work, something like declare() 
is definitely needed
- Maintaining such changes to the engine / parser could turn out messy, e.g. 
lots of "if (experimental_x)"-like code in the core
- The test suite would possibly have to deal with an exponential explosion of 
experimental feature combinations to make sure they don't interfere with each 
other.

All in all I'm not sold yet that the benefit outweighs the cost of this 
approach.

Regards,
- Chris

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

Re: [PHP-DEV] Experimental features

[Christian Schneider]

Am 05.10.2022 um 15:38 schrieb Alex Wells :
> Advantages of experimental features over extensions:
> - they allow changes to the parser
> - they are universally supported (by IDE's, parsers etc) because they are
> part of a stable language release, not an unpopular/unknown extension
> - usages of them can be found in a codebase and then analysed (unlike
> extensions that don't have any kind of marker to denote them from regular
> code)
> - it's easy to implement a universal warning mechanism - for IDEs, static
> analysers and PHP itself to warn users about the consequences of using an
> experimental feature
> - they don't need a versioning mechanism, because they are effectively
> always "alpha" - i.e. non-stable, so any PHP release can introduce a
> breaking change into an experimental feature

Just to maybe have a more complete picture, here are some possible advantages 
of extensions over experimental features;
- Core developers don't have to support/maintain it (they already have a lot on 
their plate)
- Extensions have the notion of alpha/beta/stable releases and they can offer 
different versions at the same time.
- Having to install them manually makes it obvious that you are on your own if 
you use them in production but the notion of a stable extension is an 
indication that it is not completely reckless :-)

The fact that you explicitly list always being alpha as an advantage for 
experimental features makes me wonder when I would actually use them: 
- Certainly not in production? Which limits the amount of exposure such a 
feature gets to real world usage, therefore limiting the amount of insight in 
the usefulness too.
- A branch for a future version of your code? But the experimental feature 
could disappear anytime again, do you want to rely on the feature at some point 
becoming standard?

My $.02,
- Chris

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

Re: [PHP-DEV] ksort breaking change

[Christian Schneider]

Am 26.08.2022 um 18:28 schrieb Sara Golemon :
> What I can see is two noble, but conflicting ideals:
> 1/ sort() and ksort() should be consistent about their sorting algorithms.
> I think we can all agree about that in the ideal case, at least.
> 2/ Behavior within a minor release should be self-consistent and
> predictable.
> 
> Given the above, my initial inclination is to err on the side of
> conservatism for 8.0.x at the least (we're nearly at the end of our primary
> bug-fix cycle anyway) by reverting the fix on our branch.
> For 8.1, I think we have a more difficult decision to make with over a year
> of bug-fix releases to go, and I might be swayed to keep the fix around
> there.

I agree with the description of the ideals but I'm not sure why you think the 
resolution should be different of 8.0 than 8.1.

We already transitioned our existing code base from 8.0 to 8.1, including 
testing for changes due to the way numeric string are handled. I think it is 
reasonable to adapt it for 8.2 (where another round of breaking changes will 
have to be tested anyway) but I would not expect to having to do this for a 
bug-fix release 8.1.x.

That's why I'd rather have this change postponed to 8.2 (which is not that far 
off anyway).

Regards,
- Chris

Re: [PHP-DEV] ksort breaking change

[Christian Schneider]

Am 26.08.2022 um 14:19 schrieb Christoph M. Becker :
> On 26.08.2022 at 05:15, Go Kudo wrote:
> 
>> In the actively supported version of PHP, `ksort()` has been modified to
>> include BC Break.
>> 
>> https://github.com/php/php-src/issues/9296
>> 
>> This may seem like an appropriate bug fix, but it is a clear BC Break. I
>> think this change should only be introduced in PHP 8.2 and later.
> 
> In this case, the functions didn't behave as documented, namely to
> conform to the general conversion rules, which had a relevant change in
> PHP 8.0.  Apparently, this case has been overlooked when the change had
> been implemented, and only been noticed recently (what still surprises
> me).  Anyway, fixing the issue now is not really introducing a BC break,
> since code relying on the previous behavior did not conform to the
> documentation.


I don't really agree with your definition of BC break.

The behavior of the function with a mix of numeric/non-numeric string keys 
changes from 8.1.9 to 8.1.10 which in my world qualifies as a BC break.

Regards,
- Chris

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

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

[Christian Schneider]

Am 11.08.2022 um 11:03 schrieb Alex Wells :
> That’s just a concept. I’d love to bring a lot more examples in an RFC if 
> there’s more positive than negative feedback. Again, I’m more looking for 
> feedback than trying to convince someone, but I’ll showcase a couple real 
> comparisons for some context:
> 
> Compere these (copied from real world project/public composer packages):
> ```php
> $className = Str::studly(implode('_', array_slice(explode('_', 
> $file->getName()), 4)));
> // vs
> $className = $file->getName()->explode(‘_’)->slice(4)->implode(‘_’)->studly();

This reminds me of the proposed (but declined) pipe operator
https://wiki.php.net/rfc/pipe-operator-v2
but I'd still prefer to have it as a generic operator instead of using a 
pseudo-OO approach for this.
I say pseudo-OO because not everything in PHP is an object plus using the -> 
syntax IMHO muddies the water.

Regards,
- Chris

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

Re: [PHP-DEV] Stricter implicit boolean coercions

[Christian Schneider]

Am 26.04.2022 um 15:16 schrieb Andreas Leathley :
> On 26.04.22 14:47, Christian Schneider wrote:
>> There are two big reasons:
>> - BC: Checking for the truthiness of a value is very common and would 
>> require a lot of code changes.
>> - Some of us like the conciseness of "if ($foo) ...", see below
> 
> That would not be my target - in an if expression a lot more values are
> allowed anyway (arrays, objects, etc.), so this is not about determining
> truthiness, but actual conversions to a bool type, like a bool
> parameter, a bool return type or a bool property type.

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: $preserve));
# Not working any more

I assume your solution would be to add an explicit cast to bool? i.e. something 
along the lines of
array_slice($array, $offset, preserve_keys: (bool)$preserve));  
# Explicit cast to silence implicit conversion

I'm a bit worried about having to keep two different convert-to-bool rule sets 
in mind (implicit vs. explicit) and about the additional casts.

Regards,
- Chris

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

Re: [PHP-DEV] Stricter implicit boolean coercions

[Christian Schneider]

Am 26.04.2022 um 11:54 schrieb Andreas Leathley :
> I have not found any past proposals or discussions to change boolean
> coercions, so I would like to find out how the thoughts on internals are
> to change this, or if there are any reasons not to change this that I
> have not thought of.

There are two big reasons:
- BC: Checking for the truthiness of a value is very common and would require a 
lot of code changes.
- Some of us like the conciseness of "if ($foo) ...", see below

> I can also see a case for allowing the strings 'true' and 'false', and
> changing 'false' to be coerced to false, but that would be a BC break. I
> am not sure if that is worthwhile.

I'm definitely against adding more special cases like 'false'.
Side-note: Removing something like '0' => false is also a BC break, not just 
adding 'false'.

> Anything else would emit either a notice or a warning as a first step
> (to be determined). My main goal would be to make these
> probably-not-boolean usages more visible in codebases. Depending on the
> feedback here I would create an RFC and try to do an implementation (to
> then discuss it in more detail), so as of now this is mostly about
> getting some basic feedback on such a change, and if someone else has
> had any similar thoughts/plans.


One of the big issues I have with this (as well as undefined variables not 
being allowed in if ($foo)) is that the replacement constructs are clunky:
if ($foo)  =>. if (!empty($foo))

For me this is quite a regression in readability but then again that's a matter 
of taste.
And would !empty($foo) even work in your world or how would empty() be defined?

Regards,
- Chris

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

Re: [PHP-DEV] NULL Coercion Consistency

[Christian Schneider]

Am 21.04.2022 um 16:09 schrieb Rowan Tommins :
> All of that, and the "consistency" in the title of your RFC, is a complete
> distraction from the real questions:
> 
> 1) given a null input, and a non-nullable parameter, what should the
> run-time do?
> 2) what is the best way to help users update their code to be compatible
> with that new behaviour?

You are leaving out option 3 (which is not part of the RFC but should still be 
on the table IMHO):
3) Leave the behavior but change the parameter definition to nullable to match 
the implementation.

> For instance, $search = ($_GET['q'] ?? ''); is both shorter and clearer than
> $search = ($_GET['q'] ?? NULL);

Your version is lossy as you cannot distinguish between "empty query" and "no 
query was submitted" any longer.
While this is normally easily fixed checking other flags it needs additional 
work and cannot be done with a simple search and replace.

Regards,
- Chris

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

Re: [PHP-DEV] [RFC] Deprecate and Remove utf8_encode and utf8_decode

[Christian Schneider]

Am 24.03.2022 um 10:32 schrieb Rowan Tommins :
> On 23/03/2022 23:39, Juliette Reinders Folmer wrote:
>> 
>> While I agree the functions are often used incorrectly, what worries me 
>> about this RFC is that the only viable alternatives for these functions are 
>> in two optional extensions, which in practice will mean lots of projects 
>> will need to start polyfilling the old functions and/or start including a 
>> polyfill for one of the extensions, as they can not rely on those optional 
>> extensions being turned on.
>> 

[...]

> If these functions were proposed today, under better names but the same 
> feature set, I don't think mbstring being optional would be accepted as 
> reasoning for adding them to core. So the only reason to keep them is if 
> they're widely (and successfully) used, which I've not found evidence for.

This argument is somewhat broken: Not adding something because an alternative 
exists is not the same as removing something (requiring code changes) where an 
alternative exists.

Don't get me wrong: I'm on the fence if deprecating and later removing is the 
right thing to do, I'm not completely against it.

I have one issue with the wording in the RFC: While “Function utf8_encode is 
deprecated; check usage is correct and consider mb_convert_encoding or other 
replacement.” suggests to replace it, the part about checking the usage implies 
that if someone is sure about the correct usage it is fine to keep using 
utf8_encode(). But as the proposal wants to remove it for 9.0 I think this is 
somewhat misleading.

Regards,
- Chris

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

Re: [PHP-DEV] Discussion: String streams

[Christian Schneider]

Am 22.03.2022 um 16:14 schrieb Sara Golemon :
> So while I said I wanted to avoid the firestorm suggesting userspace
> overloading would bring, maybe that's the question to ask:
> 
> Who's just a hard-nope on userspace operator overloading?  If your reasons
> go beyond foot-gun (and that is a valid reason), could you share what those
> reasons are?


An obvious one could be complexity.

In the discussion about warning in conjunction with type juggling it was 
mentioned that this leads to increased complexity in the PHP core. While my 
knowledge of the engine is too superficial to really know I'd assume that 
generic operator overload could lead to quite some additional complexity and/or 
overhead.

But I'm sure other people know better than me what the real costs are.

Regards,
- Chris

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

Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion

[Christian Schneider]

Am 16.03.2022 um 11:39 schrieb Mark Randall :
> On 16/03/2022 09:17, Christian Schneider wrote:
>> Maybe we should ask ourselves the question: Why would the entire package be 
>> blocked? Just because it is too big or maybe there *are* subtleties which 
>> have not been properly resolved?
> 
> It's politics and the practicalities of getting things done.

A nice description of salami slicing tactics ;-)

> An all-or-nothing approach will inevitably end up with nothing, because those 
> who are opposed on principle need only rally around attacking the weakest 
> element, without the need to address any of the other parts which might 
> individually be much stronger.
> 
> That's not to say that the weakest elements shouldn't be debated, they should.
> 
> But we shouldn't sabotage ourselves, and bring about a state of permanent 
> project paralysis, by mandating that semi-related weaker changes are bundled 
> with stronger ones and must be voted on as a whole.
> 
> It would just open the door to the constant use of a poison pill argument.


The problem is you are saying "the weakest should be debated but not right now, 
let's move forward anyway" and you are also stipulating that the changes are 
only semi-related.

By doing that you're dismissing Patrick's notion that they are more closely 
related than you acknowledge because he's saying having inconsistent handling 
of undefined stuff is also a WTF.

And at the same time I really hope once we start discussing undefined array 
indices you won't bring up consistency with undefined variables (and possibly 
object properties) as the reason to change it. That would feel weird given that 
you want to treat them as separate issues right now ;-)

- Chris

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

Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion

[Christian Schneider]

Am 16.03.2022 um 10:00 schrieb Mark Randall :
> On 15/03/2022 23:02, Patrick ALLAERT wrote:
>> I am not against the fact this warning becomes an error per se. I am just
>> not very fan of cherry-picking an individual kind of problem (read:
>> notice/warning/error/...) and changing it without a more global frame.
> 
> I think we should try to hit all of them, ideally in time for PHP 9.
> 
> That was the premise behind: https://externals.io/message/116918
> 
> It will likely take several RFCs until we've got it in the state we want it, 
> some of those are more contentious than others (such as undefined array 
> indexes).
> 
> I think undefined property access should throw too, and will likely have 
> supermajority support, but let's do it in a separate RFC.
> 
> What I don't think we want is the entire package being blocked because a 
> particular item (i.e. array keys) is contentious.


This is actually exactly what Patrick is complaining about: No global plan.

I know I'm on the "losing" side of this discussion but sometimes it feels like 
one of the main arguments is "we already changed this and that to exceptions, 
now we have to do it in this case too". Which, to me, fits the first paragraph 
of https://en.wikipedia.org/wiki/Salami_slicing_tactics

Maybe we should ask ourselves the question: Why would the entire package be 
blocked? Just because it is too big or maybe there *are* subtleties which have 
not been properly resolved?

- Chris

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

Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throw a deprecation notice ?

[Christian Schneider]

Am 16.03.2022 um 06:52 schrieb Juliette Reinders Folmer 
:
> I've just been looking in detail at the Partially Supported Callables 
> deprecation RFC: 
> https://wiki.php.net/rfc/deprecate_partially_supported_callables
> 
> The RFC explicitly excludes the `is_callable()` function and the `callable` 
> type from throwing deprecation notices.
> 
>> The |is_callable()| function and |callable| type remain side-effect free and 
>> do not throw a deprecation warning. They will continue to accept these 
>> callables until support is removed entirely. 
> 
> While I can fully support this for the `callable` type, I wonder if the 
> decision to not throw a deprecation on use in `is_callable()` is the right 
> one (though I understand the desire to keep it side-effect free).
> 
> Consider these code samples:
> 
>  function foo(callable $callback) {}
>  foo('static::method');
> 
> This function call not throwing a deprecation is not problematic as in PHP 
> 9.0 the function will start throwing a TypeError.

My reaction to your last sentence is actually quite the opposite: This is a 
major problem because code which was "just working" directly goes to a 
TypeError without a migration phase warning about it. This is something I've 
repeatedly advocated against.

>  if (is_callable('static::method')) {
>  static::method();
>  }
> 
> The second code sample, however, is problematic, as in PHP 9.0, the behaviour 
> of this code will be silently reversed for those callbacks which would 
> previously result in `is_callable()` returning true, which makes this a 
> potentially dangerous change without deprecation notice.

I agree with you here: Code which silently changes behavior is also a migration 
hassle.

- Chris

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

Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion

[Christian Schneider]

Am 15.03.2022 um 20:07 schrieb Miguel Rosales :
> Christoph M. Becker wrote on 15/3/22 19:17:
>> That explicitly excludes undefined array indexes, and apparently also
>> excludes undefined properties (which raise "Warning: Undefined property:")
>> 
> AFAIU error promotion for undefined properties has already been covered by 
> the Deprecate Dynamic Properties RFC 
>  >, which will start 
> throwing errors in 9.0.

That RFC covers the *creation* of undefined properties, not the *reading* of 
undefined properties.

- Chris

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Christian Schneider]

Am 03.03.2022 um 10:11 schrieb Kalle Sommer Nielsen :
> Den tor. 3. mar. 2022 kl. 10.48 skrev Sergey Panteleev 
> :
>> 
>> I'd suggest making a PR with the News (press release) in web-php
>> and maybe discussing it already on GitHub,
>> since it would get more coverage and we can hear more opinions.
> 
> The moment you do that, you put the PHP project into making a stance
> on every politics and world events, like BLM, are we also now gonna
> have an LGBT banner too? No, the PHP project is not a place for such.

I don't think you do.

Even if a project stays neutral on most topics does not mean there is not a 
threshold where joining a wide-spread appeal or sign of solidarity is the right 
thing to do.

The question where you set that threshold is a different question.
Personally I'd support a banner on the website but won't hold it against people 
who think otherwise.

Disclosure: I'm Swiss, and even (in)famously off-hands Switzerland decided to 
join sanctions in this case ;-)

Regards,
- Chris

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

Re: [PHP-DEV] Allowing NULL for some internal functions

[Christian Schneider]

Am 01.03.2022 um 11:43 schrieb Christoph M. Becker :
> On 28.02.2022 at 23:11, Christian Schneider wrote:
> 
>> Am 28.02.2022 um 22:05 schrieb Christoph M. Becker :
>> 
>>> On 28.02.2022 at 21:51, Craig Francis wrote:
>>> 
>>>> And after all of this, no-one has come up with a way to find or address
>>>> this problem, e.g.
>>>> 
>>>> >>> $nullable = ($_GET['a'] ?? NULL);
>>>> echo htmlentities($nullable);
>>>> ?>
>>> 
>>> >> function my_htmlentities(string|null $value) {
>>>   return htmlentities($value ?? "");
>>> }
>>> 
>>> $nullable = ($_GET['a'] ?? NULL);
>>> echo my_htmlentities($nullable);
>>> ?>
>>> 
>>> The BC break doesn't appear to be that serious after all.
>> 
>> I'm not sure I get your point here: If you provide a user-land 
>> implementation of the previous behavior under a different name then the BC 
>> break cannot be serious?
> 
> I said, the BC break doesn't appear to be *that* serious.
> 
> To elaborate: in my opinion, it is a good thing if internal functions
> and userland functions behave the same regarding parameter types.


... just so it is mentioned as well (again, sorry): The other way of making 
internal functions behave like user land functions would be to change the 
definition of the internal function to
function htmlentities(?string $value) { ... }
and casting it to string internally which would make the 
definition/documentation/behavior consistent while staying backward compatible.

And while a purist might think this is the end of the world because null is 
evil I'm still looking for evidence where this pragmatic approach would lead to 
a real harm or security issues going unnoticed.

Speaking of user land wrappers around internal functions: If you really are 
that worried about invalid input to something like htmlentities then I'd 
suggest that you add even more checks to your htmlentities-like function, e.g. 
checkout for double-encodings. If you're dealing with various data sources this 
will help you catch *visible* problems. And a check for null can be very easily 
added there if you want to ;-)

I guess my conclusion is that the BC break ("damage") for these basic functions 
is not worth it since you need more checks in user land than relying on the 
relatively basic PHP type system ("benefit") in any real world application.

That's why I'm advocating for consistency by changing these basic function 
definitions instead of their behaviors.

- Chris

Re: [PHP-DEV] Allowing NULL for some internal functions

[Christian Schneider]

Am 28.02.2022 um 22:05 schrieb Christoph M. Becker :
> On 28.02.2022 at 21:51, Craig Francis wrote:
> 
>> And after all of this, no-one has come up with a way to find or address
>> this problem, e.g.
>> 
>> >  $nullable = ($_GET['a'] ?? NULL);
>>  echo htmlentities($nullable);
>> ?>
> 
>  function my_htmlentities(string|null $value) {
>return htmlentities($value ?? "");
> }
> 
> $nullable = ($_GET['a'] ?? NULL);
> echo my_htmlentities($nullable);
> ?>
> 
> The BC break doesn't appear to be that serious after all.

I'm not sure I get your point here: If you provide a user-land implementation 
of the previous behavior under a different name then the BC break cannot be 
serious?

- Chris

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

Re: [PHP-DEV] Allowing NULL for some internal functions

[Christian Schneider]

Am 07.02.2022 um 13:07 schrieb G. P. B. :
> On Mon, 7 Feb 2022 at 09:34, Christian Schneider  <mailto:cschn...@cschneid.com>> wrote:
> > If a parameter expects a string, that is what it should be given, and its 
> > the callers' responsibility to ensure that is the case. If they fail to do 
> > so then it's an error just like any other.
> 
> The decision to define e.g. strlen() as strlen(string $string) instead of 
> strlen(?string $string) was arbitrary and I for one would prefer the loose 
> definition.
> 
> - Chris
> 
> I'm not sure what you are getting on here? strlen() was always defined to 
> only take a string and never was nullable in the first place.

Now this is a little bit misleading: Before 7.0 we did not have scalar type 
hints so the documentation of strlen(string $string) was somewhat lying, 
especially because back in those days the automatic type jugging from null to 
"" was used a lot.

> The RFC which is at the heart of this is the one to make internal functions 
> and userland functions consistent.
> Therefore introducing a mechanism which makes only *some* functions special 
> and weird is a complete no go for me.
> Either there is a (strong) case for the parameter to be nullable, and then it 
> should be marked as such and not do weird shenanigans with regards to 
> strict_types (which I dislike more and more by the second), or there is not.

So you are basically saying that we should discuss making it
strlen(?string $string): int
which would be cleaner, I agree.

About the case having to be strong: I could also argue that you have to make a 
strong case on why null should not be allowed any more (any more as per 
implementation, not documentation) as it is a seizable BC.

There are other things which can go wrong with strlen() on a higher level (e.g. 
misuse with utf-8) and I would like to see a real world code where strlen(null) 
actually broke something while not generating any other error in the code path.

- Chris

Re: [PHP-DEV] Allowing NULL for some internal functions

[Christian Schneider]

Am 07.02.2022 um 09:35 schrieb Mark Randall :
> On 07/02/2022 01:27, Craig Francis wrote:
>> I know one person simply said this was a "terribl > idea", but I'm still
>> waiting to hear any details on why.
> 
> I understand your motivations in proposing them, but to my mind it goes 
> against the direction that PHP is developing, which I think is the right one, 
> where errors and likely errors result in stopping execution rather than 
> allowing it continue, potentially silently (dependent on error handling 
> settings).

I think some proposals for PHP are going too far with strictness so I very much 
like Crag's RFC.

> If a parameter expects a string, that is what it should be given, and its the 
> callers' responsibility to ensure that is the case. If they fail to do so 
> then it's an error just like any other.

The decision to define e.g. strlen() as strlen(string $string) instead of 
strlen(?string $string) was arbitrary and I for one would prefer the loose 
definition.

I'm confident that any real world example would abort at an early enough stage 
to catch errors in your program, without something as basic as strlen() having 
to do the job while adding complexity for something as simple as "if 
(strlen($x)) ..".

> IMHO reverting to "If it's a null we'll just pretend its a string" is 
> contrary to how the language should be progressing.
> It sucks that it was ever allowed in the first place.

I think we agree to disagree here ;-)

> PHP has a long history of making descisions to try to make things 'just 
> work', and if history teaches us anything, its that we inevitably come to 
> regret these descisions down the line.


PHP has a long history of being a concise, pragmatic language and there are 
many who do not regret this at all.
Finding the right balance is key here.

- Chris

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

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Christian Schneider]

Am 30.01.2022 um 16:55 schrieb Nikita Popov :
> Something I want to add here is that there is also an important technical
> motivation behind promoting undefined variable notices to exceptions: The
> big problem with these (from a pure implementation perspective) is that we
> need to throw the warning and continue running. But the warning might call
> a custom error handler, which may modify state that the virtual machine
> does not expect to be modified. The PHP VM plays increasingly complex games
> to prevent this, but despite all that complexity, this problem cannot be
> fully solved while this remains a warning, rather than an exception.


Just so it has been mentioned: This could also be addressed by removing the 
warning (-:C

Out of curiosity: If undefined variables would be turned into exceptions, is 
the fact that now almost every operation can throw an exception that much 
easier to handle?

- Chris

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

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Christian Schneider]

Am 29.01.2022 um 20:03 schrieb Mark Randall :
> On 29/01/2022 16:33, Christian Schneider wrote:
>> If a static analyzer manages to catch it at development time then that is a 
>> lot better.
> 
> Of course it's better, but you wouldn't argue that a car doesn't need airbags 
> because you've tested that the breaks work.

To stay with your car analogy: A driving assistant system (especially when 
wrongly interpreted as auto-pilot) can lead drivers to not paying attention to 
the road any more. Which means even systems designed to help can have negative 
effects.

> With runtime checking, the engine should always try to protect against the 
> unexpected, irrespective of if other checking has already been performed by 
> outside sources.

I think we've been over this: I don't think the engine should force me to write 
too much unnecessary stuff just because I have to tell it I am sure I mean what 
I wrote. There is a balance between explicit declarations and conciseness, we 
just disagree where the sweet spot is.

I do for example admire the power of Haskell's type system but I would never 
want PHP to try to implement it.

Regards,
- Chris

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

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Christian Schneider]

Am 28.01.2022 um 23:57 schrieb Jordan LeDoux :
> 
> On Thu, Jan 27, 2022 at 12:24 AM Christian Schneider  <mailto:cschn...@cschneid.com>> wrote:
> 
> My issue with this is that while it seems to work towards the goal of "fail 
> fast" it does not completely fulfill its promise.
> 
> 
> Pardon me, but this argument seems rather impotent. Only fully realized 
> features are allowed? What if there is not agreement on the details of some 
> of the edgecases? Something better should be rejected because it's not 
> something perfect?

I was probably too brief there, let me elaborate a bit.

An error on reading an undefined variable does the "fail" part. And it 
partially delivers on the "fast" part as it fails at the first access, not at a 
later point.
But, and that was my point, it is still failing at runtime, maybe long after 
deployment if it is in an obscure code path.
If a static analyzer manages to catch it at development time then that is a lot 
better.

This has an impact on how I evaluate the positive effect of error-on-undefined 
and so far my conclusion was a net-negative compared to the current situation.

Side-note: An additional downside of having the increased safety net on reading 
undefined variables can be that developers think they do not need to have other 
checks like a static analyzers which might do an even better job to make their 
code better. But that's not my main point.

- Chris

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Christian Schneider]

Am 27.01.2022 um 23:41 schrieb Mark Randall :
> What we don't want to do, I think, is end up in a situation like JS where it 
> has to be opted in: https://www.w3schools.com/js/js_strict.asp

That's why the majority decided a while ago that you don't have to opt-in right 
now: The default error_reporting level shows a warning.

What you want to do is take away the option of *opting out* of this warning. 
And that's where I disagree.

Regards,
- Chris

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

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Christian Schneider]

Am 27.01.2022 um 05:17 schrieb Mark Randall :
> It is my firm believe that a language such as PHP should not be dependent on 
> static analysers to protect users against engine-level problems that may 
> occur during runtime.

My issue with this is that while it seems to work towards the goal of "fail 
fast" it does not completely fulfill its promise.

What do you gain by making undefined variables an error? You force developers 
to sprinkle their code with variable initializations where they might be sure 
that the well-defined behavior of undefined variables is fine in their code. 
Why is that a problem?

One of the burdens of early statically typed languages was that you had to 
declare everything in detail. It was with the advent of type inference that 
some of the typing overhead could be reduced and a balance between safety and 
readability through DRY was reached.

Forcing to initialize everything moves PHP against DRY while the safety gained 
by aborting the program is debatable, even though better approaches (like 
static analysis) are available now. To me it's about using the right tool for 
the right job.

> However, internals is not responsible for getting people to use a static 
> analyser, we are responsible for the behaviour of the engine, and right now 
> the engine is, I think, too lax in this regard.

My counterpoint would be that there are other topics where internals decided 
that something is better handled in user-land than on the engine level.

You could say that the engine can provide an additional layer but I could 
counter that it discourages people from using a static analyzer because they 
have a (possibly false) sense of security.

> That you're manually patching PHP to change official behaviour (which was 
> passed by RFC) puts your individual use case well outside of what should be 
> considered when voting.


Let me explain: First we were suppressing some warnings in an error_handler 
(and we are not the only ones doing it) and the decision to go one step further 
was taken because we didn't want to pay the performance penalty after 
collecting enough experience with not having this warning.

While you may disagree with that approach it is still an indication that there 
are different views on this, which should be considered.
The loser of a vote should not be completely ignored ;-)

Anyway, I think we've covered the two sides of the story quite well now, I'll 
refrain from making this thread longer than necessary.

Regards,
- Chris

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

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Christian Schneider]

Am 26.01.2022 um 17:42 schrieb Craig Francis :
> While I did begin an RFC to allow *some* functions to be more tolerant of
> NULL, especially for those scripts not using `strict_types`:
> 
> https://wiki.php.net/rfc/allow_null
> 
> Or in other words, to "relax certain type requirements on a case by case
> basis", ref the original discussion:
> 
> https://externals.io/message/112327
> 
> The only feedback I've received is that it's a "terrible idea" (no
> details), "it's a bit late" (deprecations have already been issued, full
> steam ahead?), and the typical objections/negativity (-4 points on
> externals.io, not quite a record, but getting there).

For the record: I'm in favor of pursuing this RFC, I think disallowing null for 
functions like strlen does more harm than good.

Regards,
- Chris

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

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Christian Schneider]

Am 26.01.2022 um 16:55 schrieb Lynn :
> I don't want to waste time trying to figure out if an undefined `$j++` is a 
> bug because it should've been `$i++`, or that `$i = 0;` is supposed to be 
> unused because someone forgot to remove it. Given the legacy I work with, 
> it's unrealistic to have static code analysis implemented in these projects 
> within a foreseeable time due to the sheer size. Updating PHP to a newer 
> version will get development time because we can't stay behind, thus 
> enforcing these good standards.

My experience is quite the opposite: Systems will stay on older PHP versions 
for much longer so they do not having to deal with the work. Especially for 
shared hosting services.
Which is even worse in my books.

> Imo convenience is not a good argument to write code that's potentially 
> bugged and harder to grasp for the reader.

This is where we disagree: I think being able to use undefined variables and 
indices avoids boiler plate code and can make it easier to read.

But then again I know that this is all highly dependent on your environment.
I'm only trying to get across that it is IMHO not a clear-cut decision if such 
a change is worth it. That's all.

Regards,
- Chris

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

[Christian Schneider]

Am 25.01.2022 um 00:47 schrieb Mark Randall :
> ** Undefined Variables Promoted to Error **
> 
> PHP currently treats reading an undefined variable as though it were a null, 
> emitting a warning message in the process. This was previously promoted from 
> a notice in the PHP 8 engine warnings RFC.
> 
> At the time a 3 way vote was held between promoting to an error exception, a 
> warning, or leaving it as a notice.
> 
> At the time, 56% voted in favour of throwing an Error, 28% in favour of a 
> warning, and the remainder leaving it as a notice.
> 
> My understanding is that many of those who voted to raise it to a warning did 
> so because they felt that jumping straight from a notice to an Error was too 
> much in one go.
> 
> As it will have been a warning for around 5 years by the time PHP 9 is 
> released, I expect that there will now be a healthy super majority to bump 
> this up to throwing an error.



I do not think we should make undefined variables (and array indices?) an error:
1) Static analysis has gotten a lot better and catches most of this, often even 
earlier than the runtime check.
2) Hot take: I still consider the well-defined constructs like $count++ or 
$counts[$word]++ to be useful. That's why we actually patch our  PHP to not 
emit warnings for undefined variable or index ...
3) ... which could be impossible at some point once the engine internally makes 
assumptions that the program does not continue after an undefined variable. But 
then again maybe I worry too much :-)

I'll vote 'no' on this one again and would ask you to consider leaving this 
(like many other things) to the realm of static analyzers instead of 
hard-wiring it in the engine, even if you don't use undefined variables 
personally.

Please don't flame me, I just wanted to point out that there is an opposing 
view on internals to consider ;-)

Regards,
- Chris

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

Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key

[Christian Schneider]

Am 31.12.2021 um 03:21 schrieb Kirill Nesmeyanov :
> I support this behavior fix because in its current form, due to a similar 
> problem (almost?), all PSR-7 implementations contain bugs that violate 
> RFC7230 (section 3.2:  
> https://datatracker.ietf.org/doc/html/rfc7230#section-3.2 ). Thus, 
> physically, by the standard, all headers can have the name "0" (like «0: 
> value»), but when stored inside implementations, it is converted to a string 
> and a problem arises ($message->getHeaders() // returns array string> instead of array).
> 
> To solve this problem without BC, it seems to me that Nikita's idea with 
> «declares» is most suitable, like:
> ```
>  declare(strict_types=1, strict_array_keys=1);
>  
> $array["0"] = 42; // array(1) { string(1) "0" => int(42) }
> ```


I probably sound like a broken record but I'd strongly advise against it as it 
creates language dialects which means a line like
$a["0"] = 42;
behaves differently depending on context, e.g. copying code from Stackoverflow 
might lead to subtle bugs and reminds me way too much of the ini-settings 
magic_quotes_gpc.

My take is that changing behavior is ok if it can go through a 
deprecation/warning phase but that is IMHO not the case here.

If people want to have different behavior I'd rather have a new type like
$a = new Dict;
$a["0"] = 42;
possibly with a short-hand for initialization.

Regards,
- Chris

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

Re: [PHP-DEV] Allowing NULL for some internal functions

[Christian Schneider]

Am 02.12.2021 um 16:19 schrieb Sara Golemon :
> I would say that such applications should consider unifying their own
> types.  $a = $_GET['q'] ?? '';   Is there a place in the application where
> empty string and null would have been distinct? i.e. Is a search for
> nothing different from not searching?

Being able to detect if a parameter was present and empty or it it was not 
present at all can be useful. That is the whole point of null, even though some 
people dislike null :-)

In fact we ran into the same problem and are silencing certain notices, 
warnings and deprecations because they get in the way of our code base. 
(Side-note: We are patching it instead of suppressing it in an error handler as 
we saw a noticeable performance difference.)

For the curious, here is our patch:
perl -0777 -i.bak -pe 
's#zend_error.*E_(NOTICE|WARNING|DEPRECATED).*(\n.*)?(Undefined|Attempt to read 
property|Uninitialized string offset|Trying to access array offset on value of 
type|Passing null to parameter)#if (0) 

Re: [PHP-DEV] Adding `final class Deque` to PHP

[Christian Schneider]

Am 20.09.2021 um 10:36 schrieb Pierre :
> Le 20/09/2021 à 02:03, tyson andre a écrit :
>> I've created a new RFC https://wiki.php.net/rfc/deque to add a `final class 
>> Deque`
> 
> It seems that you are writing more than one RFC to add many data structures. 
> I love that you're doing that, but I suggest that you'd normalize them all 
> and place all new classes in a single new dedicated namespace.

+1

- Chris

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

Re: [PHP-DEV] Make strtolower/strtoupper just do ASCII

[Christian Schneider]

Am 17.09.2021 um 10:43 schrieb Nikita Popov :
> The locale-sensitivity of strtolower() only works with legacy
> single-byte encodings and as such is of questionable usefulness even in
> cases where it is not actively harmful.
> 
> That said, I do think this change requires an RFC.

I agree that this is a big enough BC to require an RFC and I'd recommend a 
phase where strtolower in combination with locales where it *did* make 
something useful to show a deprecation warning to allow migration away from 
strtolower in those cases.

- Chris

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Christian Schneider]

Am 17.09.2021 um 04:09 schrieb tyson andre :
> I've created a new RFC https://wiki.php.net/rfc/vector proposing to add 
> `final class Vector` to PHP.


First of all: I don't have a strong opinion on a Vector class being useful or 
necessary.

But I have two comments about this RFC:
1) Using the very generic name Vector without any prefix/namespace seems 
dangerous and asking for BC breaks.
2) I don't like that this class is final. The reasons given in 
https://wiki.php.net/rfc/vector#final_class 
 seem unconvincing to me and 
restrict the usage of Vector in a way which makes me question the usefulness to 
a big enough part of the PHP community.

These two reasons combined would make me reject the RFC at the current stage.

- Chris

Re: [PHP-DEV] Alias stdClass to DynamicObject?

[Christian Schneider]

Am 06.09.2021 um 18:08 schrieb Benjamin Morel :
> Yes, please! A future where dynamic properties are only allowed on
> DynamicObject is bright.

I have nothing against a DynamicObject alias for people who like to be more 
explicit in their code...

> I would even deprecate the stdClass alias straight away, so that the whole
> thing can be gone in PHP 9.

... but I'd prefer retaining a backward compatible version for library code, at 
least for a while and preferably without warnings :-)

- Chris

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

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

Am 06.09.2021 um 16:46 schrieb Pierre Joye :
> Also as someone mentioned here afterwards, instead of removing it
> straight away, I would go with the flag first, less risky :)

Out of curiosity: Do you think disabling the stat cache could be harmful?
If no, why make it an option?
If yes, should we be allowing it?

Follow-up question: What would be the default?
Cache off which might be harmful to some (assumedly bigger) sites?
Cache on which won't fix the bug reports?

If you put the burden on the bigger PHP users by making it default to off 
you're assuming they have more rigorous update procedures, I guess. Probably 
true, just make sure that it is mentioned prominently enough in UPGRADING.

Ok, I've said my piece :-)
- Chris

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

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

Am 05.09.2021 um 13:30 schrieb Kevin Lyda :
> Any more thoughts on https://github.com/php/php-src/pull/5894 ?
> I've resolved the merge conflict. It would be nice to close out this bug.

For the record in case it was missed:
If we deem the stat cache to be useless I'd rather remove it completely to 
avoid further WTFs based on a hoster's configuration.

- Chris

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

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

Am 03.09.2021 um 18:12 schrieb Kevin Lyda mailto:ke...@lyda.ie>>:
> To run this php script:
> 
>  $iterations = 100;
> function all_the_stats($filename) {
>   @lstat($filename);
>   @stat($filename);
> }
> while ($iterations--) {
>   all_the_stats(__FILE__);
> }
> 
> I see this output:
> 
> Without cache
> 
> real 0m7.326s
> user 0m5.877s
> sys 0m1.448s
> With cache
> 
> real 0m5.010s
> user 0m5.009s
> sys 0m0.000s

So this is almost a 50% performance regression ;-)
And the more interesting number for me here is "sys 0m1.448s" vs "sys 
0m0.000s". Which means 1.5s out of the additional 2.3s are spent in system 
calls.
Side-note: Why is the user time without cache higher than with cache? That 
seems counter-intuitive. Maybe the checking of the ini-settings or some 
libc-code?

I'm interested in the load put on a system with a high request count and a 
typical application.
Reducing system calls used to matter there as the kernel does not multi-process 
the same way user land does.

But then again, maybe I'm overly cautious :-)

Regards,
- Chris

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

Am 03.09.2021 um 17:23 schrieb Nikita Popov :
> Just to throw it out there: Maybe we should clear the stat cache when 
> functions in the exec family are used? Even if we allow disabling the stat 
> cache, I think we can easily avoid that particular footgun. And if calls to 
> external binaries are involved we likely don't have to worry about stat 
> overhead.

While this would make the foot gun a bit smaller it introduces more magic. I'm 
not completely against it but it feels dirty.
On top of that: I hope people using exec and friends are properly escaping 
parameters. Which in our case is a helper function where a clear_stat_cache() 
could easily be added in user land, making it explicit.

Side-note: We should teach people not to use exec style function when normal 
PHP functions work :-)
The following works fine:

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

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

Am 03.09.2021 um 16:07 schrieb Kevin Lyda :
> On Fri, Sep 3, 2021 at 2:34 PM Christian Schneider
>  wrote:
>> If I remember correctly it was about reducing the number of system calls. Is 
>> this no issue any more?
>> Has a quick benchmark been done to see the positive / negative impact of the 
>> stat cache for a typical application?
> 
> In the lifespan of php it really wasn't an issue unless someone was
> doing something that wasn't wise - I can't think of a single reason to
> stat a file in a tight loop.

How can you say "it never was a problem" if we never had to live without stat 
cache?
Can you back up that claim with numbers? There are some of us who run 
high-volume websites where system load increase could be a problem.

> However more importantly the current behaviour returns bad data for
> perfectly correct programs. So for example on a unix box...
> 
>  passthru('touch foo');
> if (is_file('foo')) {
>echo "Correct\n";
> }
> passthru('rm foo');
> if (is_file('foo')) {
>echo "Incorrect\n";
> }
> ?>

I disagree that this (with current PHP) is a correct program. The documentation 
at

https://www.php.net/manual/en/function.is-file.php#refsect1-function.is-file-notes
 <https://www.php.net/manual/en/function.is-file.php>
clearly states that is_file() is cached and clearstatcache() should be used.

Yes, the stat cache is a foot gun, but it was put in for a reason back in the 
day.

> Personally I value correctness first and then performance is a
> priority further down that list of attributes (security and
> readability would also be higher priorities). However as the current
> behaviour has existed for several decades, this change makes sure the
> incorrect historical behaviour is the default.


There are two problems here:

a) Removing the stat cache altogether (which is not your proposal, I know, but 
it was mentioned in the thread) could lead to a performance regression. I was 
asking for data backing up the claim that this regression either does not exist 
or is small enough to not be a problem. Just saying "it never was a problem" or 
"modern Linux should handle this" does not give me that certainty.

b) Making it an .ini-Option seems to be a BC preserving measure but, in fact, 
it creates an even bigger issue: Your code snippet is correct or buggy 
depending on an ini-settings. Something we want to avoid as much as possible, 
see magic_quotes :-)

- Chris

Re: [PHP-DEV] Adding a way to disable the stat cache

[Christian Schneider]

Am 02.09.2021 um 13:15 schrieb Kevin Lyda :
> Removing it completely would be ideal, however a number of people objected
> in the linked bug. And while it's not needed in modern Unix operating
> systems, it's not clear if Windows might benefit from this.


If I remember correctly it was about reducing the number of system calls. Is 
this no issue any more?
Has a quick benchmark been done to see the positive / negative impact of the 
stat cache for a typical application?

Just curious,
- Chris

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

Re: [PHP-DEV] [PROPOSAL] Bare name array literals (again)

[Christian Schneider]

Am 21.06.2021 um 18:54 schrieb tyson andre :
> return [success: true, data: $data, cursor: $cursor];
> // is equivalent to the following, but shorter:
> return ['success' => true, 'data' => $data, 'cursor' => $cursor];

Just a little side-note: A while ago I proposed a 2-line-patch to allow :$foo 
as a synonym for 'foo' => $foo.

This allows for
return ['success' => true, :$data, :$cursor];
which is both shorter and removes repetition while keeping the variable usage 
$data and $cursor visible.

I know that this has been shot down before but I couldn't resist mentioning it 
in this context, sorry ;-)

- Chris

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

Re: [PHP-DEV] Policy for procedural style in new additions

[Christian Schneider]

Am 03.06.2021 um 22:47 schrieb Kamil Tekiela :I love this 
idea. We should definitely make it official that procedural
> style API is unfavourable and should not be added to new classes.
> On top of that, I would be in favor of deprecating all existing procedural
> APIs.
> - It's making it more difficult to maintain code in two variants
> - It's making it difficult to maintain documentation
> - It's confusing for users
> - Procedural API is usually much more verbose than OO style
> - The return values often do not match

While I understand your points and especially see the benefit for maintainers, 
I'm not a fan of make-everything-OO-with-exceptions.

This leads to more exceptions creeping into otherwise exception-free code. I 
assume that some people don't see a problem with that but it can end up using 
exceptions for flow control which is frowned upon even by some exception 
enthusiasts.

As soon as you start mixing ifs and exceptions it tends to get messy because 
you might even end up converting ifs to exceptions like
try {
$date = new DateTime($datestring);
if ($limit > $maxlimit)
throw new Exception(...);
...
} catch (Exception $e) {}
as opposed to
if ($date = date_create($datestring) and $limit <= $maxlimit)
...

I'm fine with new OO style APIs not providing a procedural equivalent but I'm 
wary about deprecating/removing existing ones.

Final remark: I think neither procedural nor OO style is the right choice for 
everything. I believe it should be decided individually.

- Chris

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

Re: [PHP-DEV] Disable autovivification on false

[Christian Schneider]

Am 25.05.2021 um 18:23 schrieb Kamil Tekiela :
> I'd like to start a discussion on the following RFC
> https://wiki.php.net/rfc/autovivification_false
> Particularly, I am looking for opinions on whether this behaviour should be
> left alone, should be disabled on false, or should be disabled on null and
> false, and left only for undefined variables.
> 
> Autovivification is very useful in PHP, especially with multidimensional
> arrays and loops. However, the question is should we allow it on false and
> null values going forward.



I feel like a broken record, but I have to say it (again):
Please add an E_WARNING step before changing something that used to be silent 
to an error. For easier migration.

Thanks,
- Chris

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

Re: [PHP-DEV] Discussion: Object-scoped RNG

[Christian Schneider]

Am 11.05.2021 um 23:20 schrieb Larry Garfield :
> 3) Perhaps it should be named RandomSequence or similar?  It's not truly 
> generating random numbers.  It's generating a repeatable but difficult to 
> produce sequence off of a seed value.  That's not the same thing as 
> random_int() et al.
> 
> So, at first pass, an API could be as simple as (pseudocode):
> 
> class RandomSequence {
>  public function __construct(int $seed = time(), $algorithm = 'some_default') 
> { ... }
> 
>  public function next(): int { ... }
> }
> 
> And that's it.  That's nice and simple and predictable to use.


Would the generated values fill the whole int range, i.e. 64 bit on modern 
systems?

And would it make sense to add max and min for the generated values like we 
have with random_int()?
Because mapping arbitrary int values to a specific range is error-prone: Just 
using modulo leads to bias in the resulting values.

- Chris

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Christian Schneider]

Am 11.05.2021 um 19:02 schrieb Calvin Buckley :
> - almost all modern mail clients are threaded, it's trivial to view
> context, so I want to see replies "above the fold"

Funnily enough the fact the mail clients are threaded nowadays is a good reason 
for me to use inline replies with rigorously trimmed down context: Someone who 
is actively following the thread will have minimal overhead to see what I'm 
referring to and people new to the thread can scroll to previous messages to 
get up-to-speed.

> - bottom posting goes against the grain of modern mail clients

First of all: I'm advocating inline quoting, not bottom posting.
I don't think this against the grain of modern clients. I have no problem going 
through my reply step by step, removing what is irrelevant to my reply and 
leave in what it relevant. At the same time it helps me to not forget something 
I wanted to answer. Yes, maybe mobile phones are a bit less well-equipped for 
this task but someone deciding to write detailed answers on a mobile phone 
should be willing to pay this price for the sake of the readers.

> I personally top-post (as it's the default for all the mail clients I
> use) when replying unless it's a point-by-point reply, in which case I
> reply inline.

I think you're pointing out exactly why a lot of long-time users of mailing 
lists prefer inline replies: Your personal (or even work) emails might often 
consist of nothing more than "I agree" or "Let's meet up", mailing lists are 
used for more in-depth discussions.

This means that the threshold for writing to the mailing list should be higher, 
i.e. a mail will probably contain multiple parts like an introduction, an 
explanation and a conclusion or question.
Therefore answers are often more complex too and reply to multiple points.

Another reason I sometimes hear at work is that you can forward a top-posting 
emails more easily to someone new to a thread. But this applies much less to a 
mailing list as people are normally subscribed to the list already and even if 
not there is an archive of all messages they can check for older messages if 
necessary.

Now while inline replies work for both point-by-point replies as well as short 
answers (you just strip down the original text to a minimum before adding your 
one-liner) the same is not true to top or bottom posting. They only work in 
simple cases unless you want to either copy/paste or (worse) paraphrase the 
original text within your answer. Both of these options are basically weaker 
versions of the inline quoting style (which as an additional bonus also support 
multiple levels of quoting).

Sure, some answers can be simple enough for top/bottom posting, but then again 
you have to ask yourself: Is this interesting enough for the 100s of people on 
this mailing list?
And if inline quoting works almost as well for simple answers, why not use it 
all the times so the reader does not have to switch reading modes?

- Chris

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

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Christian Schneider]

Am 11.05.2021 um 18:42 schrieb Kamil Tekiela :
> Compare the two messages from Sara, the first where she top posted and the
> second where she bottom posted. Which one is more clear?
> https://imgur.com/TUiHval

The second one which shows me what Sara is referring to.
Imagine it just said "I don't know what Mel is talking about" without you 
seeing what Mel said right away.

> I completely agree with Good Guy. Top posting is just way more convenient.


I disagree.
What some people call inter-posting as way more convenient because it has the 
context of what you are referring to right next to your answer.

And yes: People *should* trim down the context. It also forces you to go 
through the email and remove what is irrelevant. Every second you spend making 
your message clearer and quicker to digest will save many seconds on the 
reading end.

- Chris

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

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Christian Schneider]

Am 11.05.2021 um 17:01 schrieb Mel Dafert :
>>> 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 emails, I am not able to find it.

As long as the Android Gmail App includes a text/plain version alongside the 
html one, everything is fine.

And as far as I can see (doing a quick and not too comprehensive test with a 
friend who has the app installed) it does, so no need to configure anything.

- Chris

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

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Christian Schneider]

No.
Outlook is not modern.
No.
That's not the point, the missing context is.

Sorry, could not resist ;-)

- Chris


> Am 10.05.2021 um 23:51 schrieb Kamil Tekiela :
> 
> Hi Internals,
> 
> Could we drop the bottom-posting rule?
> 
> Almost all new contributors fall into this trap and reply to a thread by
> top-posting, only to get chastised by someone else on the list. It's really
> difficult to remember to delete the default reply. Mail clients don't make
> it easy for us; it's hidden by default. Bottom-posting makes reading the
> thread much more difficult too. The actual reply gets lost in between the
> quoted content. I often get confused about what is new and what was
> quoted. Many modern clients are designed to handle top-posting and don't
> handle bottom-posting well. People are usually used to it and they read
> from top to bottom. I don't know if in the past some mail clients defaulted
> to bottom-posting but right now it just seems like an unnecessary
> annoyance.
> 
> If you want to quote someone then it makes sense to copy a part of the
> message and then add a reply below, but forcing people to remove the
> default reply from the mail client and then add the whole previous message
> on top of your own reply isn't very productive. It wastes time and screen
> space.
> 
> Could we please change this rule or at least stop enforcing it?
> Do people actually have mail clients that don't automatically hide the
> previous conversation? If not, then I think we can let people top-post.
> 
> Regards,
> Kamil

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

Re: [PHP-DEV] PR for minor bugfix in compact()

[Christian Schneider]

Am 07.05.2021 um 03:44 schrieb Ben Ramsey :
> On 4/28/21 06:17, G. P. B. wrote:
>> On Wed, 28 Apr 2021 at 12:12, David Gebler  wrote:
>>> Hi internals,
>>> I've opened a PR to cause compact() to throw a TypeError if its parameters
>>> are not valid, which I consider to be a fix for what is effectively a bug
>>> whereby logical errors in user code can be silently swallowed.
>>> 
>>> GPB has done an initial review and left a comment
>>> https://github.com/php/php-src/pull/6921#pullrequestreview-646848902 in
>>> which he suggests I open this up to the floor, so here it is, seeking
>>> your feedback kindly. Also if anyone can clarify what is meant by a warning
>>> "will be promoted in PHP 9", I am not familiar with what changes are
>>> planned for the next major version?
>>> 
>>> Regards
>>> David
>>> 
>> Hey David,
>> What I meant is that we usually don't introduce an exception without prior
>> warning to existing functionality.
>> So making this a Warning in the PHP 8 series which gets promoted to a
>> TypeError in PHP 9,
>> similarly to how most of the internal functions went from returning null +
>> warning to throwing a TypeError,
>> or many of the warnings that got promoted to ValueErrors in 8.0 because
>> it's a major release.
>> Personally I don't mind introducing the TypeError immediately in PHP 8.1,
>> because compact() should be rather rare
>> and mostly used on an array, but others might feel differently about this.
>> Best regards,
>> George P. Banyard
> 
> Does anyone have any thoughts or concerns about this being in 8.1? I'm trying 
> to decide whether to merge the PR, and I'd like to make sure anyone who wants 
> to speak up has a chance to do so.



I agree with George that it should be an E_WARNING first and then changed to a 
TypeError in PHP 9.
This should be the default process for reasons given in many other threads 
about tightening type rules IMHO.

So no, I'd prefer if this PR to be changed to E_WARNING before merging it.

- Chris

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

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and short functions take 2

[Christian Schneider]

Am 29.04.2021 um 10:14 schrieb Rowan Tommins :
> On 28/04/2021 23:00, Nuno Maduro wrote:
> 3) All variables are captured, there is no local scope. This is effectively 
> what PHP's single-expression closures use.
> 
> Option 3 is the easy option, and is currently "good enough" because it's rare 
> to need a purely local variable within a single expression. For a full 
> function body, local variables are much more likely, so we now need to think 
> about the question more carefully.
> 
> Without a keyword like "var" to declare it, I think most users would assume 
> that an initialisation like "$foo=null;" at the top of their closure would 
> make a variable local.


This assumption by the users would be true as we are capturing by value, not by 
reference.

At the same time it feels like abusing a side-effect. But adding some sort of 
explicit local variable declaration seems even worse (as in even less PHP-like) 
to me.

This illustrates why I'm wary of / opposed to auto-capture for multi-line 
closures.

- Chris

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

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Christian Schneider]

Am 28.04.2021 um 01:00 schrieb Larry Garfield :
> However!  Classic OOP design patterns are not all that PHP supports, and 
> that's a good thing.  The "class" construct, for better or worse, is the 
> syntax for logic objects, value objects, data objects, and control flow 
> objects (such as Maybe, Either, etc.), plus assorted other patterns that are 
> not part of the classic OOP canon.  But they're still good and useful 
> patterns, and often a better model than classic OOP "polymorph all the 
> things" approaches.
> 
> If we were designing PHP from scratch today, I'd argue for having separate 
> language constructs for funcy-syntax-closures (which is what service objects 
> are), product types (structs, value objects, all the same thing), and control 
> flow types.  Many newer languages do differentiate those better.  That's not 
> where we are, though, so we're stuck with class being the uber-syntax for 
> anything even slightly interesting from a type perspective.  So be it, but it 
> does lead to ample confusion about which use case you're talking about, 
> especially when not everyone is familiar with all of the different, distinct 
> use cases.
> 
> See also: This thread. :-)
> 
> Sealed classes are... not really useful at all for service object use cases.  
> They are useful for product type and control flow type use cases.


... and ...

Am 28.04.2021 um 09:39 schrieb Pierre :
> Yeah, final is something, I originally come from the Java world 20 years 
> back, and it never hit me as something terrible in PHP, on the contrary, I 
> use it "per default" personally to promote composition over inheritance, but 
> when I do that I mostly write interface and composition based APIs which much 
> more flexibility than an open to extension design (TL;DR: I always give the 
> user an escape route other than inheritance, and document it).

Those are good points you are bringing up.
You're basically saying that classic OOP has outlived itself in many cases - 
something I agree with - and we need the ability to use other patterns.

With that in mind I'm not sure if we really want to tack all this functionality 
on to "class".
I think it would be better and less confusing to most developers if we were to 
bite the bullet and try to do it right.
Especially since my impression is that we only need to tack it on to "class" if 
there is urgency and personally I'm not feeling it.
But then again YMMV.

You convinced me from a -1 to considering abstaining from the vote ;-)

- Chris

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

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Christian Schneider]

Am 27.04.2021 um 19:19 schrieb Pierre :
> I think that the debate "but if your seal your classes I won't be to extend 
> it" is overrated: it's not the language to chose whether or not the 
> library/software author can seal its classes or not, it's up the 
> library/software author to do its own choice. And in that regard, having 
> "sealed" classes in the language is actually bringing that possibility to the 
> library author, so it's more liberty.


The same - "it is more liberty" - could be said about operator overloading, 
multiple inheritance and many other language features which lead to people 
using them in ways / places I consider harmful. So I'd rather not have them in 
my language of choice.

I'm not saying the feature is completely useless in the right hands but I think 
it will be misunderstood and promotes bad habits. Think people abusing 
exceptions for flow control.

But then again maybe I'm just traumatized by people putting final all over the 
place in Java back in the days. I'm sure people in 2021 know better than that 
/s ;-)

- Chris

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

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Christian Schneider]

Am 26.04.2021 um 14:18 schrieb Ilija Tovilo :
> The point of sealed type is to fix the number of subclasses a given
> type can have, which means you can handle a value by type (as that
> list is not finite). Code that handles Optional values could look like
> this:
> 
> ```
> if ($option instanceof Option\None) {
>throw new Exception();
> }
> 
> // We now know the value is a Some
> var_dump($option->value);
> ```

I really hope that's *not* the way people will use the Maybe type

> If you suddenly provide your own version of None the code above will
> break.

... but no, it wouldn't break, as MyNone extends None, so instanceof would 
still work.

> To most people it's obvious that you can't add new cases to an
> existing enum.

The RFC does not mention data classes (at least not explicitly), it talks about 
sharing common functionality.
So I think you're somewhat moving the goal posts.
If you want to limit Enums only then I would have to reconsider, but we were 
talking about generic classes AFAIK.

> It doesn't sound sensible to add logging to a data
> class. That's something that belongs into a hook or service of some
> kind.

You're again making assumption about what's sensible for the user of a library, 
that's the mind-set I would like to avoid.

> People might also want to use sealed for behavioral classes, the use
> case here is the same as final. Final is not here to make your life
> harder. It's here to make the lives of the library maintainers easier.

First of all: Yes, I'm no fan of final either.
I've encountered enough examples where it *did* make my life harder.
And as a library writer myself I value the user experience higher than the 
library developer work because there are (hopefully) a lot more users than 
developers.

> If they have to reason about every way a method could be overridden,
> every change in the library would become more risky, require more
> thought and more frequent major version updates.

A properly designed API should be simple and stable enough to not need this 
kind of safe-guards.
Overly complicated, cathedral-style frameworks might yearn for it but I think 
it's addressing the symptoms, not the cause (-:C

> This means more work and less features for you, too.


That kind of argument reminds me of people saying that user tracking is a good 
thing because I get to see more relevant advertisement.
You're a good sales-man though, I give you that, but you haven't convinced me 
yet ;-)

- Chris

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Christian Schneider]

Am 25.04.2021 um 05:47 schrieb Larry Garfield :
> In practice, I think all of the use cases for sealed classes are ADT-esque.  
> As I noted before, combining sealed classes with Nikita's new-in-expressions 
> RFC would allow for this (also using my short-functions RFC for this example, 
> although that's a nice-to-have):
> 
> sealed class Maybe permits Some, None {

...

> }
> 
> final class None extends Maybe {}



This is exactly the thing I'm worried about.

Say I want to add something like logging to the None type.
Now your sealed and final classes prevent me from defining MyNone extending 
None even though it would be 100% compatible with None. Just because *you* 
deemed that useless or wrong.

I've encountered situations like this and came to the conclusion that while 
this makes sense for languages like Haskell - where the whole idea is to be 
able to reason about a complex type system - it is an anti-pattern for other 
languages like PHP.

Referring to another post, not yours: People, please don't use Java as a reason 
to add something to PHP, Java is the king of anti-patterns ;-)

- Chris

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Christian Schneider]

Am 24.04.2021 um 21:51 schrieb Marco Pivetta :
> On Sat, Apr 24, 2021, 21:44 Olle Härstedt  > wrote:
> 
>> 2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati :
 Doesn't this violate the principle: It should be possible to add new
 features without touching old code?
>>> 
>>> This depends on which syntax is picked, both `for` and attribute syntax
>> will
>>> be completely BC.
>> 
>> I'm not talking about BC, but the maintainability of the new feature
>> itself. For the shape example, you'd need to edit the original file
>> for each new shape you add, which is detrimental for maintainability
>> and scalability. So what's a good use-case?

I'm with Olle here: This sounds like an anti-pattern to me.
The example could not be worse: Why should I not be allowed to add a hexagon 
shape?

> The main use-case of sealed types is being able to declare total functions
> around them.

Could you elaborate on what's the real-world use-case for your main use-case?
This sounds like another case of a feature based in (math) theory which leads 
to artificially locked down code.

- Chris

Re: [PHP-DEV] [RFC] [Draft] Final constants

[Christian Schneider]

Am 21.04.2021 um 17:08 schrieb Andreas Leathley :
> On 21.04.21 15:14, Christian Schneider wrote:
>> I never really understood the desire to restrict how people can use
>> your code.
>> If there is no good reason to override the value of a class constant people 
>> won't do it.
>> If there might be a good reason (even one you as the original designer 
>> didn't predict) then why not leave that door open.
>> 
>> While I understand the theoretical benefit of being able to specify this 
>> behavior I do think it is almost always counter productive and not a pattern 
>> I would encourage. Especially not in a dynamic language like PHP.
> 
> Such restrictions also convey information and intent. One could argue
> defining a specific return type to a method is restricting its use, but
> it also clarifies how something should work and avoids unintended
> changes.

To me, the term 'constant' is good enough for that...

> final constants might be more niche, but it gives you a choice
> on how you want a class constant to behave if child classes are
> necessary and possibly done by someone else.

... but if child classes are necessary then how can you say that the constant's 
value should never be different for children?
Why not leave that to the user of your class? I've seen my share of damage done 
by assumptions about how code will be used later.

> Having "final" for constants seems a good addition to me, especially if
> the inconsistent behavior with interface constants can be solved at the
> same time.


Fixing this inconsistency should be discussed separately IMHO. Both because it 
is a side-effect and should not be used as a reason to add 'final' as well as 
not fixing the problem for code *not* using 'final' with constants.

Side-note: Back in my Java days people argued with performance to add 'final' 
but that only lead to it being sprinkled all over the place making code less 
flexible than it needed to be without real performance benefit. That's what I 
mean by promoting harmful patterns.

- Chris

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

Re: [PHP-DEV] [RFC] [Draft] Final constants

[Christian Schneider]

Am 21.04.2021 um 14:25 schrieb Máté Kocsis :
>> My point is actually what’s your scenario for a final constant? If you
>> want to make sure the value you access are not changed by child class,
>> `self::` can serve the purpose already. If you want to make sure
> 
> 
> Yes, my intention is to actually make class constant overriding impossible
> when it is desired. You can't really achieve this with only using self::,
> since you can only control your own code. Yes, I know that child classes
> could still declare a new class constant to overcome this limitation, but
> at least there will be no doubt what they should expect if they try to
> override the constant value. Otherwise, they have to check whether the
> parent class uses self:: or static:: calls.


I never really understood the desire to restrict how people can use your code.
If there is no good reason to override the value of a class constant people 
won't do it.
If there might be a good reason (even one you as the original designer didn't 
predict) then why not leave that door open.

While I understand the theoretical benefit of being able to specify this 
behavior I do think it is almost always counter productive and not a pattern I 
would encourage. Especially not in a dynamic language like PHP.

- Chris

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

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and short functions take 2

[Christian Schneider]

Am 25.03.2021 um 17:25 schrieb Larry Garfield :
> So in conclusion, it seems the reasons closures weren't auto-capture always 
> were:
> 
> 1) Possible performance concerns that are no longer relevant.
> 2) Avoid surprise references.
> 3) Allow users to capture by value or by reference.
> 
> Point 1 is no longer relevant as the engine has changed so much.
> Point 2 is no longer relevant since forever, since capture is by-val by 
> default.
> Point 3 is only relevant in the cases where you need to capture by reference, 
> which in practice it turns out are really quite rare.
> 
> So, I would argue that all of the reasons for manual capture in the first 
> place are no longer relevant, except in the edge case where you really do 
> want to capture by reference.

While the discussion back then revolved a lot around performance and references 
I don't think

4) Local-as-default scoping and explicit captures are the PHP way and make it a 
better language

which was mentioned in this thread should be buried ;-)

- Chris

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

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Christian Schneider]

Am 25.03.2021 um 14:29 schrieb Mark Randall :
> On 25/03/2021 09:28, Rowan Tommins wrote:
>> That's not quite what I meant. I meant that you can't say "capture by 
>> default, but this variable is definitely local".
> 
> I think if there's one argument against, this would be it, but IMHO it is a 
> weakness in PHP as a whole.

I'm not sure if I misunderstand what you're saying but to me it is one of the 
greatest things about PHP that everything is local by default (minus a narrow 
set of well-known and easily enough recognizable things).

> The solution would be adding JS-like let / const statements. Which would be a 
> benefit to other things too.


I disagree that this is the solution. I think JS had to add var and later let 
because of the unfortunate decision to have C-like scoping rules.
Making scoping in PHP more complex to be able to repeat this mistake in some 
form seems ill-advised to me.

- Chris

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

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and short functions take 2

[Christian Schneider]

Am 24.03.2021 um 18:15 schrieb Chase Peeler :
> I guess my one question would be why we didn't support auto-capture when we
> first implemented anonymous functions, and if there was a reason, why does
> that no longer apply?

My guess would be that it was seen as one of PHP's big strength that variables 
don't just leak into other contexts but that it has to be done explicitly.

Now with arrow functions both the benefit of auto-capturing is bigger compared 
to the actual function 'body', it normally only spans a line or two and (for me 
personally) the absence of {} also kind of make the leakage fit my mental model 
more easily.

For these reasons I think I lean towards -1 for both 
https://wiki.php.net/rfc/short-functions 
 and 
https://wiki.php.net/rfc/auto-capture-closure 
 as they add more syntax without 
(IMHO) a huge benefit.

You might be able to convince me otherwise though ;-)
- Chris

Re: [PHP-DEV] [RFC] Autoloader Classmap

[Christian Schneider]

Am 17.03.2021 um 02:51 schrieb Mark Randall :
> It will be left to the voters to decide if 5% of an extremely common 
> operation is worth the few dozen lines of code required.


Just to avoid misunderstanding things: This is a 5% boost of just the 
autoloading time, right?
What does this translate to - before vs. after, e.g. in ms - for a real-world 
project, everything included?

I'm still undecided if I'm in the this-is-not-worth-it or the 
it-is-simple-enough-to-add camp.

- Chris

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

Re: [PHP-DEV] [RFC] Autoloader Classmap

[Christian Schneider]

Am 15.03.2021 um 18:41 schrieb Mark Randall :
> I would like to propose the addition of a new mechanism of autoloading 
> classes - a classmap that will be consulted prior to checking the 
> spl_autoload_register'd callbacks.
> 
> https://wiki.php.net/rfc/autoload_classmap


Just so I understand correctly: This is all about performance, right? Because 
an autoloader providing this functionality is basically a one-liner, correct?

If the number of classes to load is indeed that big that the function call 
overhead is significant enough (I agree with Levi that some numbers 
illustrating what we're talking about would be nice), wouldn't that be a case 
for class preloading to really speed things up?

My first impression is that it's a band-aid for overly big class hierarchies 
without going all the way.
Again, maybe some benchmarks could shed some light why this needs to be 
included in the core.
Or maybe I'm missing something.

- Chris

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

Re: [PHP-DEV] [PHP-DEV] [VOTE] Fibers

[Christian Schneider]

Am 11.03.2021 um 17:51 schrieb Chase Peeler :
> If someone is willing to do the work to
> add this to core, we aren't trading off other features in order to add it,
> and it doesn't cause BC breaks or other bugs, what is the reason to not add
> it?


Complexity, which might come back and bite us in the long run.

Note: I'm not talking about this specific feature, more in general. I just 
wanted to point out that there can be reasons to *not* add something even 
though it doesn't seem to have a drawback at the moment.

- Chris

Re: [PHP-DEV] Small annoyances of PHP: Simple fixes would make tests fail

[Christian Schneider]

Am 19.02.2021 um 16:21 schrieb Sara Golemon :
> On Fri, Feb 19, 2021 at 8:04 AM Christian Schneider  <mailto:cschn...@cschneid.com>> wrote:
> Indentation in var_export:
> 
> The indentation for
> var_export((object)[(object)[]]);
> is off by one for nested structures:
> (object) array(
>'0' =>   # <-- extra space before index
>   (object) array(
> and the fix would be to change
> buffer_append_spaces(buf, level + 2)
> to
> buffer_append_spaces(buf, level + 1)
> in ext/standard/var.c
> 
> This breaks about 60 PHP tests relying on the var_export format.
> 
> 
> I think shifting the indentation in var_export() could probably be done 
> without a major BC break.  Trimming trailing whitespace would also resolve 
> one of my long-time annoyances with the function.
> Feel free to propose that as a PR and/or an RFC.

There is a PR fixing both the indentation and removing the trailing spaces: 
https://github.com/php/php-src/pull/6724

Do you think this needs an RFC?

- Chris

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Christian Schneider]

Am 04.03.2021 um 01:37 schrieb Ben Ramsey :
> On Mar 3, 2021, at 14:25, Kamil Tekiela  wrote:
>> 
>> when both are strings then chances are that this is an error.
> 
> Except when comparing two values from sources known to provide numbers as 
> strings, such as form input and database results. :-)


This would be a problem for leading zeroes and leading/training spaces, right?

Leading zeroes theoretically could happen in databases, leading/training spaces 
happen in form input and possibly databases.
Are there other 'common' cases?

- Chris

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

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Christian Schneider]

Am 03.03.2021 um 21:25 schrieb Kamil Tekiela :
> Sorry Nikita, but adding special handling for edge-cases is only going to
> make things messier.


I didn't want to say that, as there is plenty of code out there who might fall 
in this trap this intermediate measure might still make sense.
The good old quick-fix - warning - better fix cycle :-)

- Chris

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

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Christian Schneider]

Am 03.03.2021 um 19:21 schrieb Stanislav Malyshev :
> Nobody who applies == to strings and expects it to work out as stri g 
> comparison is doing the right thing. If you apply == to hex-encoded hashes, 
> that code is fubar, and fixing one particular corner case won't rescue it. So 
> I wonder if fixing one particular corner case while leaving many others in 
> would do much.


Just brainstorming, but following that logic, if we would like to remedy this 
in the long run:
a) Should == with two strings where one (or both?) of them is numeric cause an 
E_NOTICE or E_WARNING that === should be used?
b) Should == with two strings leave them as string? Possibly after a period of 
notice/warning as described in a)?

I haven't really thought this through but I still wanted to throw it out there.
I'm sure you'll tell me how foolish I am and why this is a very bad idea ;-)

- Chris

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

Re: [PHP-DEV] Replies on lists.php.net

[Christian Schneider]

Am 15.02.2021 um 13:20 schrieb Pierre :
> I noticed I receive almost all your replies to the list along with a 
> duplicated copy addressed to me or other conversation participants, I think 
> you always click "reply to all" instead of "reply to list" in your mail 
> client.

I think if our intention is that the default reply should go to the list then 
the mailing list should be configured to include a
Reply-To: "php internals" 
header which it currently does not, right?

This would make it harder to send a reply directly to the author (in some 
clients you have to click reply and then copy the address) but it would not 
depend on the reply-to-list feature not all mail clients have.

- Chris

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

Re: [PHP-DEV] Small annoyances of PHP: Simple fixes would make tests fail

[Christian Schneider]

Am 19.02.2021 um 16:21 schrieb Sara Golemon :
> On Fri, Feb 19, 2021 at 8:04 AM Christian Schneider  <mailto:cschn...@cschneid.com>> wrote:
> Stack traces:
> ==
> 
> What version are you testing with. I know Niki killed some unnecessary frames 
> in 8.0's stacktrace output. (A whole repro script is more useful than a 
> snippet wherein $e comes into being seemingly from nowhere).

I was testing with PHP 8.0.3 but it is the same with master.
You can see the difference at https://3v4l.org/0Pgfo <https://3v4l.org/0Pgfo> 
where the first line
try { $a[(object)null] = 1; } catch (Throwable $e) { 
print_r($e->getTrace()); }
does not create a stack trace. That's what I'd like to change.

What do you think? Should I create a PR for this?
It does break a lot of tests in PHP. Probably less so for other projects but 
still...

> Indentation in var_export:
> 
> The indentation for
> var_export((object)[(object)[]]);
> is off by one for nested structures:
> (object) array(
>'0' =>   # <-- extra space before index
>   (object) array(
> and the fix would be to change
> buffer_append_spaces(buf, level + 2)
> to
> buffer_append_spaces(buf, level + 1)
> in ext/standard/var.c
> 
> This breaks about 60 PHP tests relying on the var_export format.
> 
> 
> I think shifting the indentation in var_export() could probably be done 
> without a major BC break.

An example script is at https://3v4l.org/V8r5k <https://3v4l.org/V8r5k>
It does break tests though. And my guess it that is would also break tests in 
quite some projects.

What version would you aim this for? 8.1? 9.0?

> Trimming trailing whitespace would also resolve one of my long-time 
> annoyances with the function.
> Feel free to propose that as a PR and/or an RFC.

I see your point as it means there have to be trailing white-spaces in tests 
which can be confusing when editing/creating tests.
I can have a look at how hard this would be to fix...

Side-note: Maybe we should recommend a function to be used for tests. At my 
work we used to use var_export(), some of our newer tests are using 
json_encode() but neither is really guaranteed to be stable, right?

- Chris