Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function

[Lynn]

On Fri, May 3, 2024 at 9:28 AM Lynn  wrote:

>
> The parameter number always confuses me because parameter 4 is actually
> the 4th, not the 3rd like I'd expect if I look at the indexes when
> `...$parameters`.
>

I wish we had a proper system so I could edit my message instead of
bothering everyone with an additional reply, I meant to say index 3, not
the 3rd parameter.

Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function

[Lynn]

On Thu, May 2, 2024 at 10:21 PM Benjamin Außenhofer 
wrote:

>
>
> On Thu, May 2, 2024 at 2:51 PM Ollie Read  wrote:
>
>> Hi All,
>>
>> I've been working on a PR that introduces
>> ReflectionFunctionAbstract::getParameter() and
>> ReflectionFunctionAbstract::hasParameter(), to fall more inline with the
>> other method sets we have, as well as just generally making peoples lives
>> easier.
>>
>> The PR is here: https://github.com/php/php-src/pull/10431
>>
>> These methods accept an integer to retrieve a parameter by its position,
>> or a string to retrieve by its name. So far, I have built this so that if
>> you required the first parameter, it's parameter 0. I treat it this way
>> because the only other place where we deal with parameter indexes, is
>> ReflectionFunctionAbstract::getParameters() which returns the parameters
>> zero-indexed.
>>
>> The question that is holding this PR back is should these methods be 1
>> indexed, so that the provided position is consistent with the error
>> messages, or how a person would typically count, or should they be 0
>> indexed to remain consistent with the existing API.
>>
>
> PHP being a mostly zero indexed language I would say it should be
> getParamter(0) to get the parameter #1 (referred to as 1 in error
> messages).
>
>>
>> Girgias has asked that I pause the PR until we can have a discussion on
>> this mailing list about how to approach it, so I'm looking for feedback on
>> this.
>>
>>
>> ---
>> Best Regards,
>> *Ollie Read*
>>
>>
The parameter number always confuses me because parameter 4 is actually the
4th, not the 3rd like I'd expect if I look at the indexes when
`...$parameters`. Whenever I get an error about parameters I always have to
triple check and it costs me extra time to verify the number. I wouldn't
mind having this number be consistent with the array indexes instead. I
write Lua on a regular basis and everything starts with 1, but it's
consistent in the behavior so I never have to think twice.

Re: [PHP-DEV] [RFC] [Discussion] #[\Deprecated] attribute again v1.3

[Lynn]

On Tue, Apr 23, 2024 at 3:30 PM Benjamin Außenhofer 
wrote:

> Hi internals,
>
> My PR for #[\Deprecated] attribute was in hibernation for a long while now
> and after some off-list discussion a few weeks ago I have decided to
> revisit it and asked Tim to help me out with the work.
>
> Tim has cleaned up the PR quite a bit and also worked in additional
> features such as #[Deprecated] support in stub generation.
>
> While there are still some small todos, at this point we want to restart
> the discussion about the RFC for inclusion in 8.4:
>
> RFC: https://wiki.php.net/rfc/deprecated_attribute
> PR: https://github.com/php/php-src/pull/11293
> Old discussion: https://externals.io/message/112554#112554
>
> Let me know about your questions and feedback.
>
> greetings
> Benjamin
>

JetBrains was mentioned in the previous discussion but not sure if this was
considered in the RFC:
https://github.com/JetBrains/phpstorm-attributes/blob/master/src/Deprecated.php

Re: [PHP-DEV] [RFC] [Discussion] new MyClass()->method() without parentheses

[Lynn]

On Tue, Apr 23, 2024 at 1:20 PM Robert Landers 
wrote:

> On Tue, Apr 23, 2024 at 11:10 AM Valentin Udaltsov
>  wrote:
> >
> > вт, 9 апр. 2024 г. в 19:41, Larry Garfield :
> >>
> >> On Mon, Apr 8, 2024, at 6:08 AM, Valentin Udaltsov wrote:
> >> > Hello internals,
> >> >
> >> >
> >> >
> >> > I would like to propose a syntax change for PHP 8.4 that allows to
> >> > immediately access instantiated objects without wrapping the
> expression
> >> > into parentheses.
> >> >
> >> >
> >> >
> >> > This was requested and discussed several times, see:
> >> >
> >> > - https://externals.io/message/66197
> >> >
> >> > - https://bugs.php.net/bug.php?id=70549
> >> >
> >> > - https://externals.io/message/101811
> >> >
> >> > - https://externals.io/message/113953
> >> >
> >> >
> >> >
> >> > Here's what you will be able to write after this change:
> >> >
> >> > ```php
> >> >
> >> > class MyClass
> >> >
> >> > {
> >> >
> >> > const CONSTANT = 'constant';
> >> >
> >> > public static $staticProperty = 'staticProperty';
> >> >
> >> > public static function staticMethod(): string { return
> 'staticMethod'; }
> >> >
> >> > public $property = 'property';
> >> >
> >> > public function method(): string { return 'method'; }
> >> >
> >> > public function __invoke(): string { return '__invoke'; }
> >> >
> >> > }
> >> >
> >> >
> >> >
> >> > var_dump(
> >> >
> >> > new MyClass()::CONSTANT,// string(8)  "constant"
> >> >
> >> > new MyClass()::$staticProperty, // string(14) "staticProperty"
> >> >
> >> > new MyClass()::staticMethod(),  // string(12) "staticMethod"
> >> >
> >> > new MyClass()->property,// string(8)  "property"
> >> >
> >> > new MyClass()->method(),// string(6)  "method"
> >> >
> >> > new MyClass()(),// string(8)  "__invoke"
> >> >
> >> > );
> >> >
> >> > ```
> >> >
> >> >
> >> >
> >> > For more details see the RFC:
> https://wiki.php.net/rfc/new_without_parentheses
> >> >
> >> > Implementation: https://github.com/php/php-src/pull/13029
> >>
> >> I always thought there was some technical parser reason why this wasn't
> possible.  Maybe that was true in 5.x but isn't anymore?
> >>
> >> I cannot speak to the implementation, but I'm all for the change itself.
> >>
> >> --Larry Garfield
> >
> >
> > Does anyone have additional feedback? I'd like to start voting on
> Thursday, April 25th.
> > I've also added a section on other syntax ideas that have been expressed
> on Twitter and in the PR:
> https://wiki.php.net/rfc/new_without_parentheses#other_syntax_ideas
> > --
> > Valentin
>
> I suspect this will break (badly written) reflection in interesting ways:
>
> https://3v4l.org/mcSNH
>
> This basically breaks dereferencing order of operations and makes it
> inconsistent.
>
> Robert Landers
> Software Engineer
> Utrecht NL
>

I think these scenarios are all covered in the RFC under "This RFC still
does not allow to omit parentheses around the new expression without
constructor arguments' parentheses, because in some cases this leads to an
ambiguity"

Re: [PHP-DEV] PDO subclass names

[Lynn]

On Tue, Apr 23, 2024 at 11:26 AM Stephen Reay 
wrote:

>
> Sent from my iPhone
>
> On 23 Apr 2024, at 18:21, Lynn  wrote:
>
> 
>
>
> On Tue, Apr 23, 2024 at 10:21 AM Bilge  wrote:
>
>> On 21/04/2024 14:00, Saki Takamachi wrote:
>> > Hi internals,
>> >
>> > Recently I've been working on an RFC regarding object support for
>> BCMath. While working on that, I learned of the following RFC:
>> > https://wiki.php.net/rfc/namespaces_in_bundled_extensions
>> >
>> > If we follow this RFC, is it reasonable to place subclasses of PDO
>> under the namespace "PDO”?
>> >
>> > e.g.
>> > ```
>> > PdoMysql => PDO\Mysql
>> > PdoPgsql => PDO\Pgsql
>> > PdoSqlite => PDO\Sqlite
>> > PdoOdbc => PDO\Odbc
>> > PdoDblib => PDO\Dblib
>> > PdoFirebird => PDO\Firebird
>> > ```
>> >
>> > We'll probably get a BC Break if try to fix this after 8.4 is released,
>> so before it's released is last chance to fix this safely.
>> >
>> > If Tim's RFC under discussion is passed, the namespace will be "Pdo"
>> instead of "PDO”.
>> > https://wiki.php.net/rfc/class-naming-acronyms
>> >
>> > I would appreciate hearing your opinions.
>> >
>> > Regards,
>> >
>> > Saki
>>
>> Hi Saki,
>>
>> Consider that adding a namespace does not/should not change the class
>> name. That is, `MyClass` once namespaced becomes `MyNamespace\MyClass`.
>> Ergo, `PdoMysql` becomes `Pdo\PdoMysql`. The class name should still
>> make sense and be a "strong name" (without conflict) once imported.
>>
>> To state it more concretely, I believe it is normal and correct to
>> include 1-3 namespace components within the class name itself, in order
>> to create such a "strong name". As a more concrete example of this,
>> consider `HttpClient`, `FtpClient` and `SoapClient`. Far too often, we
>> see user libraries (incorrectly) namespace these as `Http\Client`,
>> `Ftp\Client` and `Soap\Client` (or similar) where the leaf name just
>> becomes `Client`. "Client", by itself is a meaningless moniker, but that
>> is all we see once the name is imported, notwithstanding importing
>> multiple of these clients in one file causes conflicts that now need to
>> be resolved with local aliases. In general, I believe aliasing to be an
>> anti-pattern that points to a failure to create strong names and thus
>> should be avoided by including some of the namespace portion in the
>> class name to make the class name more meaningful. Once imported, we do
>> not see the namespace portion within the body of the file any more;
>> `HttpClient` and `FtpClient` make much more sense by themselves, whether
>> or not they would otherwise conflict.
>>
>> Kind regards,
>> Bilge
>>
>
> The code base I work in has 25 classes that are called "Line". They have
> namespaces like `App\Model\Invoice\Line`, this is cumbersome to work with
> so I would also prefer something like `Pdo\PdoMysql`, even if it's not
> likely to conflict with a name such as Mysql.
>
>
> I don't think it's appropriate to claim that a namespace like
> MyLib\HTTP\Client is categorically "wrong".
>
> The argument that "Client" is meaningless becomes pretty moot when you
> realise that you can import a *namespace* and use it relatively, if you so
> wish:
>
> ```
> import MyLib\HTTP;
>
> $a = new HTTP\Client(...);
> ```
>
> I'm not claiming that any particular import pattern is more "correct" (and
> I think it's a bad idea to suggest that other usage patterns are
> "incorrect") but adding repetitive prefixes kind of defeats the purpose of
> namespaces.
>
> You may as well just go back to MyLib_HTTP_Client, and ignore that
> namespaces exist.
>

In your own codebase you should do what works best for you. When it comes
to vendor classes I don't want to have to scroll through a list of 20
identical classes to find the one in the right namespace. It requires extra
development and review effort to figure out if the right class called
"Client" or "Factory" is used. For reference, I have 12 "Response", 12
"Client", 20 "Factory", and 20 "TestCase" classes in this project, of which
most are vendors.

Using partially imported namespaces and aliases causes inconsistencies that
makes it harder to find things. Nobody here is advocating for
MyLibHttpClient class names either. Even in an IDE like Intellij with a
project the size I'm working with it's hard to quickly get the right
classes, especially in legacy code where some classes live in the global
namespace.

Re: [PHP-DEV] PDO subclass names

[Lynn]

On Tue, Apr 23, 2024 at 10:21 AM Bilge  wrote:

> On 21/04/2024 14:00, Saki Takamachi wrote:
> > Hi internals,
> >
> > Recently I've been working on an RFC regarding object support for
> BCMath. While working on that, I learned of the following RFC:
> > https://wiki.php.net/rfc/namespaces_in_bundled_extensions
> >
> > If we follow this RFC, is it reasonable to place subclasses of PDO under
> the namespace "PDO”?
> >
> > e.g.
> > ```
> > PdoMysql => PDO\Mysql
> > PdoPgsql => PDO\Pgsql
> > PdoSqlite => PDO\Sqlite
> > PdoOdbc => PDO\Odbc
> > PdoDblib => PDO\Dblib
> > PdoFirebird => PDO\Firebird
> > ```
> >
> > We'll probably get a BC Break if try to fix this after 8.4 is released,
> so before it's released is last chance to fix this safely.
> >
> > If Tim's RFC under discussion is passed, the namespace will be "Pdo"
> instead of "PDO”.
> > https://wiki.php.net/rfc/class-naming-acronyms
> >
> > I would appreciate hearing your opinions.
> >
> > Regards,
> >
> > Saki
>
> Hi Saki,
>
> Consider that adding a namespace does not/should not change the class
> name. That is, `MyClass` once namespaced becomes `MyNamespace\MyClass`.
> Ergo, `PdoMysql` becomes `Pdo\PdoMysql`. The class name should still
> make sense and be a "strong name" (without conflict) once imported.
>
> To state it more concretely, I believe it is normal and correct to
> include 1-3 namespace components within the class name itself, in order
> to create such a "strong name". As a more concrete example of this,
> consider `HttpClient`, `FtpClient` and `SoapClient`. Far too often, we
> see user libraries (incorrectly) namespace these as `Http\Client`,
> `Ftp\Client` and `Soap\Client` (or similar) where the leaf name just
> becomes `Client`. "Client", by itself is a meaningless moniker, but that
> is all we see once the name is imported, notwithstanding importing
> multiple of these clients in one file causes conflicts that now need to
> be resolved with local aliases. In general, I believe aliasing to be an
> anti-pattern that points to a failure to create strong names and thus
> should be avoided by including some of the namespace portion in the
> class name to make the class name more meaningful. Once imported, we do
> not see the namespace portion within the body of the file any more;
> `HttpClient` and `FtpClient` make much more sense by themselves, whether
> or not they would otherwise conflict.
>
> Kind regards,
> Bilge
>

The code base I work in has 25 classes that are called "Line". They have
namespaces like `App\Model\Invoice\Line`, this is cumbersome to work with
so I would also prefer something like `Pdo\PdoMysql`, even if it's not
likely to conflict with a name such as Mysql.

Re: [PHP-DEV] [RFC] Casing of acronyms in class and method names

[Lynn]

On Fri, Apr 19, 2024 at 8:50 PM Bilge  wrote:

> On 19/04/2024 18:42, Tim Düsterhus wrote:
>
> The two weeks of discussion are over now, the RFC didn't receive any
> substantial changes after the initial proposal, and neither was there any
> significant content-related feedback after the first few days.
>
> As such, I plan to open the vote early next week without making further
> changes to the RFC text.
>
> Best regards
> Tim Düsterhus
>
> Hi Tim,
>
> Not that my opinion counts for much, but I have to say I find this very
> odd.
>
> Good class names:
> Id // Identifier
> ID // Identity Document
>
> I understand the distinction you wish to make here, between an acronym and
> abbreviation, but I think it's a meaningless distinction. In this case,
> `Id` would be fine for "identifier", but "Identity Document" should simply
> be `IdentityDocument`. Whilst the distinction may seem meaningful to you,
> it certainly does not look that way to me; I think it would be difficult to
> remember and explain to someone else. Perhaps the tie breaker could be that
> it wouldn't be meaningful to an automated style checker, either. That is,
> it would be difficult to enforce this policy exception in any automated
> way. Why not just keep it simple and consistent here, disallowing runs of
> multiple upper-case letters?
>
> Cheers,
> Bilge
>
I was under the impression that this RFC was trying to solve exactly that,
so I'm surprised to see that ID would be allowed.

Re: [PHP-DEV] [RFC][Vote announcement] Property hooks

[Lynn]

On Wed, Apr 10, 2024 at 5:47 AM Juliette Reinders Folmer <
php-internals_nos...@adviesenzo.nl> wrote:

> On 9-4-2024 16:03, Juliette Reinders Folmer wrote:
>
> On 8-4-2024 23:39, Ilija Tovilo wrote:
>
> Hi everyone
>
> Heads-up: Larry and I would like to start the vote of the property
> hooks RFC tomorrow:https://wiki.php.net/rfc/property-hooks
>
> We have worked long and hard on this RFC, and hope that we have found
> some middle-ground that works for the majority. One last concern we
> have not officially clarified on the list:
> https://externals.io/message/122445#122667
>
> I personally do not feel strongly about whether asymmetric types make it into 
> the initial implementation. Larry does, however, and I think it is not fair 
> to exclude them without providing any concrete reasons not to. [snip]
>
> My concern is more about the external impact of what is effectively a change 
> to the type system of the language: [snip] will tools like PhpStan and Psalm 
> require complex changes to analyse code using such properties?
>
> In particular, this paragraph is referencing the ability to widen the
> accepted $value parameter type of the set hook, described at the
> bottom of https://wiki.php.net/rfc/property-hooks#set. I have talked
> to Ondřej Mirtes, the maintainer of PHPStan, and he confirmed that
> this should not be complex to implement in PHPStan. In fact, PHPStan
> already offers the @property-read and @property-write class
> annotations, which can be used to describe "virtual" properties
> handled within __get/__set, already providing asymmetric types of
> sorts. Hence, this concern should be a non-issue.
>
> Thank you to everybody who has contributed to the discussion!
>
> Ilija
>
>
>
> Ilija,
>
> Heads-up: I'm still writing up an opinion and intend to send it to the
> list before end of day (CET). I know I'm late to the party, but I've been
> having trouble finding the words to express myself properly regarding this
> RFC (and have been struggling to find the right words for months).
>
> Smile,
> Juliette
>
>
> Later than intended, but here goes
>
> If there is one RFC which has been giving me nightmares since I first
> heard of it, it's this one.
>
> I realize it is late in the discussion period to speak up, but for months
> I've been trying to find the words to express my concerns in a polite and
> constructive way and have failed.
>
> I am going to try now anyway (before it is too late), so please bear with
> me. Also, as I'm not a C-developer, please forgive me if I get the
> internals wrong. I'm writing this from a PHP-dev/user perspective, with my
> perspective being heavily influenced by my role as maintainer of
> PHP_CodeSniffer.
>
> ---
> TL;DR: this RFC tries to do too much in one go and introduces a huge
> amount of cognitive complexity with all the exceptions and the differences
> in behaviour between virtual and backed properties. This cognitive
> complexity is so high that I expect that the feature will catch most
> developers out a lot of the time.
> ---
>
> I can definitely see the use case and desirability of the property hooks
> functionality proposed in the RFC and compared to the initial RFC I read
> last year, the current RFC is, IMO, much improved.
> Huge kudos to Ilija and Larry for all the work they have put in to this!
>
> I applaud the intention of this RFC to make it easier to avoid the magic
> __get()/__set() et al methods. What I have a problem with is the
> implementation details.
>
> Over the last few years, we've seen a movement to get rid of more and more
> of the _surprising_ behaviour of PHP, with subtle exceptions being
> deprecated and slated for removal and (most) new syntaxes trying to use the
> principle of least surprise by design.
>
> This RFC, in my view, is in stark contrast to this as it introduces a
> plethora of exceptions and subtle different behaviour in a way that will
> catch developers out for years to come.
>
> At this moment (excluding property hooks), from a user perspective, there
> are three different function syntaxes in PHP: named functions (and
> methods), anonymous functions and arrow functions.
>
> The semantics of these are very similar with subtle differences:
> * Can be static or non-static.
> * Take parameters, which can be typed, references, variadic, optional etc.
> * Can have a return type.
> * Can return by reference.
> * Have a function "body".
>
> The differences between the current syntaxes - from a user perspective -
> are as follows:
> = Named functions:
> * When declared in a class, can have visibility attached, can be abstract,
> can be final.
> * When declared in an interface or declared as abstract, will not have a
> function "body".
>
> = Anonymous functions:
> * Can import plain variables from outside its scope with a `use()` clause.
> * Are declared as an expression (can be assigned to a variable etc).
>
> = Arrow functions:
> * Have access to variables in the same scope.
> * Are declared as an expression.
> * 

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

[Lynn]

On Tue, Apr 2, 2024 at 11:17 AM Jordan LeDoux 
wrote:

>
>
> On Sat, Mar 30, 2024 at 5:09 PM Saki Takamachi  wrote:
>
>> Hi Jordan,
>>
>> Your opinion may be reasonable given the original BCMath calculation
>> order. That is, do you intend code like this?
>>
>> Signature:
>> ```
>> // public function __construct(string|int $number)
>> // public function getNumber(?int $scale = null): string
>> ```
>>
>> Add:
>> ```
>> // public function add(Number|string|int $number): string
>>
>> $num = new Number('1.23456');
>> $num2 = new Number('1.23');
>>
>> $add = $num + $num2;
>> $add->getNumber(); // '2.46456'
>> $add->getNumber(1); // ‘2.4'
>>
>> $add = $num->add($num2);
>> $add->getNumber(); // '2.46456'
>> $add->getNumber(1); // '2.4'
>> ```
>>
>> Div:
>> ```
>> // public function div(Number|string|int $number, int
>> $scaleExpansionLimit = 10): string
>>
>>
>> // case 1
>> $num = new Number('0.0001');
>> $num2 = new Number('3');
>>
>> $div = $num / $num2; // scale expansion limit is always 10
>> $div->getNumber(); // '0.3'
>>
>> $div = $num->div($num2, 20);
>> $div->getNumber(); // '0.333'
>> $div->getNumber(7); // ‘0.333'
>>
>>
>> // case 2
>> $num = new Number('1.11');
>> $num2 = new Number('3');
>>
>> $div = $num->div($num2, 3);
>> $div->getNumber(); // '0.370'
>> $div->getNumber(7); // ‘0.370'
>> ```
>>
>> Since the scale can be inferred for everything other than div, a special
>> argument is given only for div.
>>
>> Regards.
>>
>> Saki
>
>
> Something like the signature for `getNumber()` in this example would be a
> decent solution. Operations which have ambiguous scale (of which truly only
> div is in the BCMath library) should *require* scale in the method that
> calls the calculation, however for consistency I can certainly see the
> argument for requiring it for all calculation methods. The issue is how you
> want to handle that for operator overloads, since you cannot provide
> arguments in that situation.
>
> Probably the most sensible way (and I think the way I handled it as well
> in my library) is to look at both the left and right operand, grab the
> calculated scale of the input for both (or the set scale if the scale has
> been manually set), and then calculate with a higher scale. If internally
> it produces a rounded result, the calculation should be done at
> `$desireScale + 2` to avoid compound rounding errors from the BCMath
> library and then the implementation. If the result is truncated, the
> calculation should be done at `$desiredScale + 1` to avoid calculating
> unnecessary digits.
>
> So we have multiple usage scenarios and the behavior needs to remain
> consistent no matter which usage occurs, and what order the items are
> called in, so long as the resulting calculation is the same.
>
> **Method Call**
> $bcNum = new Number('1.0394567'); // Input scale is implicitly 7
> $bcNum->div('1.2534', 3); // Resulting scale is 3
> $bcNum->div('1.2534'); // Implicit scale of denominator is 4, Implicit
> scale of numerator is 7, calculate with scale of 8 then truncate
>
> **Operators**
> $bcNum = new Number('1.0394567'); // Input scale is implicitly 7
> $bcNum / '1.2534'; // Implicit scale of denominator is 4, Implicit scale
> of numerator is 7, calculate with scale of 8 then truncate
>
> This allows you to perhaps keep an input scale in the constructor and also
> maintain consistency across various calculations. But whatever the behavior
> is, it should be mathematically sound, consistent across different syntax
> for the same calculation, and never reducing scale UNLESS it is told to do
> so in the calculation step OR during the value retrieval.
>
> Jordan
>

I'm inexperienced when it comes to maths and the precision here, but I do
have some experience when it comes to what the business I work for wants.
I've implemented BCMath in a couple of places where this kind of precision
is necessary, and I found that whenever I do divisions I prefer having at
least 2 extra digits. Would it make sense to internally always just store a
more accurate number? For things like
additions/multiplications/subtractions it could always use the highest
precision, and then for divisions add like +3~6 or something. Whenever you
have numbers that have a fraction like `10.5001` it makes sense to set it
to 4, but when you have `10` it suddenly becomes 0 when implicitly setting
it.

For the following examples assume each number is a BcNum:
When doing something like `10 * 10. * 10.0` I want the end
result to have a precision of at least 9 so I don't lose information. When
I do `((10 / 3) * 100) * 2` I don't want it to implicitly become 0, because
the precision here is important to me. I don't think using infinite
precision here is a reasonable approach either. I'm not sure what the
correct answer is, perhaps it's just "always manually set the precision"?

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[Lynn]

On Wed, Feb 21, 2024 at 7:58 PM Larry Garfield 
wrote:

> Hello again, fine Internalians.
>
> After much on-again/off-again work, Ilija and I are back with a more
> polished property access hooks/interface properties RFC.  It’s 99%
> unchanged from last summer; the PR is now essentially complete and more
> robust, and we were able to squish the last remaining edge cases.
>
> Baring any major changes, we plan to bring this to a vote in mid-March.
>
> https://wiki.php.net/rfc/property-hooks
>
> It’s long, but that’s because we’re handling every edge case we could
> think of.  Properties involve dealing with both references and inheritance,
> both of which have complex implications.  We believe we’ve identified the
> most logical handling for all cases, though.
>
> Note the FAQ question at the end, which explains some design choices.
>
> There’s one outstanding question, which is slightly painful to ask:
> Originally, this RFC was called “property accessors,” which is the
> terminology used by most languages.  During early development, when we had
> 4 accessors like Swift, we changed the name to “hooks” to better indicate
> that one was “hooking into” the property lifecycle.  However, later
> refinement brought it back down to 2 operations, get and set.  That makes
> the “hooks” name less applicable, and inconsistent with what other
> languages call it.
>
> However, changing it back at this point would be a non-small amount of
> grunt work. There would be no functional changes from doing so, but it’s
> lots of renaming things both in the PR and the RFC. We are willing to do so
> if the consensus is that it would be beneficial, but want to ask before
> putting in the effort.
>
> --
>   Larry Garfield
>   la...@garfieldtech.com


In regards to arrays, what about additional operations next to get/set? I
doubt this solution will cover all the use-cases or perhaps even
over-complicate things, just throwing the idea out there.

```php
class Test {
private array $_myData = [];
public array $myData {
get => $this->_myData;
append => $this->_myData[] = $value;
}
}
```

 Thinking about the other post about offset and containers (
https://github.com/Girgias/php-rfcs/blob/master/container
-offset-behaviour.md):
```php
class Test {
private array $_myData = [];
public array $myData {
get => $this->_myData;
append => $this->_myData[] = $value;
write_dimension => $this->_myData[$offset] = $value;
}
}
```

Is this issue restricted to arrays only? From my understanding objects
functioning as arrays are already by reference and thus should not suffer
from this?
```php
class Test {
private ArrayObject $_myData;
public ArrayObject $myData {
get => $this->_myData;
}

public function __construct() {
$this->_myData = new ArrayObject();
}
}

// would this work without issues?
$obj = new Test();
$obj->myData[] = 'test';
```

Re: [PHP-DEV] Re: [RFC] OOP API for cURL extension

[Lynn]

On Sun, Feb 18, 2024 at 12:41 PM Rowan Tommins 
wrote:

> On 17 February 2024 15:57:20 GMT, Larry Garfield 
> wrote:
>
> >The RFC would also benefit greatly from some practical examples of using
> the new API.  Right now it's not clear to me (as someone who almost never
> uses Curl directly) how/why I'd use any of these, since there's still "a
> whole crapton of int constants I don't understand floating around."  The
> suggestion to use an Enum (or several) here is a good one and would help a
> lot with that, so I'm +1 there.
>
> To my mind, the *eventual* aim should be that users don't *need* a
> userland wrapper just to make a simple request in a readable way, and that
> setting raw curl options becomes an advanced feature that most users never
> need.
>
> I know a lot of people's minds will immediately go to request and response
> objects, but I think we can go a long way by just making well-named methods
> wrapping one or two curl options each, so that you could write this:
>
> $ch = new CurlHandle('https://example.com');
> $ch->setMethod('POST');
> $ch->setRequestBody('{"stuff":"here"}');
> $ch->setBasicAuth('admin', 'correct-horse-battery-staple');
> $result = $ch->executeAndReturn();
>
> Note that I am not saying every one of those methods needs to be added
> right now; adding a few at a time may be sensible to have time to discuss
> good names and signatures. But to me, renaming CURLOPT_POSTFIELDS to
> Curl\StringOptionsEnum::POSTFIELDS doesn't get us very far - users
> shouldn't need a raw curl setting for such a basic feature in the first
> place.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>

 Having a lot of setters for options might make it really hard to find the
methods you're looking for in terms of auto-complete in your IDE. Would it
make sense to split options into a separate object (or perhaps multiple),
that could in theory also be shared between different CurlHandle instances?

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

[Lynn]

On Fri, Feb 2, 2024 at 2:00 AM youkidearitai 
wrote:

> Hi, Internals
>
> I have just opened the voting "Multibyte ucfirst and lcfirst functions"
> RFC.
> https://wiki.php.net/rfc/mb_ucfirst
>
> Voting will be open until February 26th, 2024 at 01:00 UTC.
>
> Cheers
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
In the proposal part is mentioned "From what I've researched with Unicode,
it may not behave as expected in some languages. In that case, please deal
with it in userland.". If my understanding here is wrong, please correct
me. ucfirst and lcfirst are to uppercase/lowercase the first character of a
word for characters that have an upper/lower case variant. Whether or not a
word _should_ have an uppercase or lower case character is not important
and currently doesn't behave in such a way for ucfirst and lcfirst. To me
this isn't unexpected behavior, that's exactly how I would expect it to
behave.

Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type

[Lynn]

On Mon, Jan 22, 2024 at 11:21 AM tag Knife  wrote:

> On Mon, 22 Jan 2024 at 09:51, Gina P. Banyard  wrote:
>
> > Hello internals,
> >
> > Máté Kocsis and myself would like to propose deprecating implicitly
> > nullable parameter types.
> >
> > The RFC is available on the wiki at the following address:
> > https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
> >
> >
> > Best regards,
> >
> > Gina P. Banyard
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
> Also just did a quick test, and i don't believe this would be possible. It
> would remove functionality from the language widely used.
> As you are mistaking `iint $var = null` params as "nullable". Which they
> are not, they are "optional default" parameters. The equals
> can be succeeded by any value, to set the parameter to such variable where
> the parameter is not passed. `int ?$arg` is not provided as
> an alternative, the directive `int ?$arg` simple allows the parameters to
> be passed as null, it is still required to pass through the
> parameter.
>
> To clarify
>
> `T ?$var` = Requires the parameter to be passed  to the function, null
> value allowed
> `T $var = null` = Does not require the parameter to be passed to the
> function, is set to null if not.
>
> https://3v4l.org/IWsqK


Your example contains `int2` as type with a default value of `null`. This
works because it implicitly marks the class `int2` as nullable. If you were
to set this default value to `1` via `int2 $int2 = 1` it breaks with "Fatal
error: Cannot use int as default value for parameter $int2 of type int2"

Anyhow, `= null` implicitly makes the parameter nullable even if the type
doesn't specify it's nullable. The argument is that if the type isn't
nullable, then the default value may not be null either.

Re: [PHP-DEV] `PDO::FETCH_CONSTRUCTOR` fetch mode proposal

[Lynn]

On Fri, Jan 19, 2024 at 1:51 AM Alexander Pravdin 
wrote:

> I would also suggest supporting readonly classes and creating special
> attributes to help map data fields to constructor arguments. Something like
> this:
>
> readonly class User {
> public function  __construct(
> #[PDOField('user_id')]
> public string $userId,
> #[PDOField('user_name')]
> public string $userName,
> #[PDOField('user_address')]
> public ?string $userAddress = '', // Optional field with default
> value
> );
> }
>
> --
> Best regards,
> Alex
>
>
> On Fri, Jan 19, 2024 at 9:05 AM Saki Takamachi  wrote:
>
> > Hi Frederik
> >
> > > First off, please excuse me if I’ve done something wrong related to the
> > usage of the mailing list. This all is completely new to me.
> >
> > Welcome to the internal mailing list! I had looked the pull request, and
> > I'm pleased to have received your email promptly.
> >
> > > Thank you, the link was originally on the text "on GitHub" but it seems
> > to have been stripped.
> >
> > Since mailing lists are text rather than HTML, you cannot attach links to
> > strings.
> >
> > > I hereby want to propose a new fetch mode for PDO. I’ve detailed the
> > motivation for it on GitHub. I haven’t actually written the code for it,
> > but it should not be too difficult.
> >
> > Now, I agree that it is often not possible to use `PDO::FETCH_CLASS`
> > because DB column names are typically snake case and variables and
> > properties are camel case.
> >
> > IMHO, passing arguments to the constructor in order is a good approach,
> > but I think another option would be to give attributes to properties and
> > map data appropriately when using PDO::FETCH_CLASS.
> >
> > e.g.
> > ```
> > #[ColumnName('user_name')]
> > private string $userName;
> > ```
> >
> > In addition to the concerns mentioned in the pull request, I'm also
> > concerned that more modes with similar functionality will confuse users.
> >
> > Regards.
> >
> > Saki
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>

Would it be interesting to see if there's a way to make the hydration of
objects more standard in PHP? PDO could then use that
underlying implementation, but so could every existing library, or even PHP
extension (SOAP/XML/JSON) that does anything related to object
hydration/(de)serialization. I'm looking at Symfony, Doctrine, and all the
other serialization/hydration/auto-mapper library maintainers) for this
because I wouldn't be able to design this myself.

Re: [PHP-DEV] What is the prevailing sentiment about extract() and compact() ?

[Lynn]

On Wed, Nov 29, 2023 at 9:20 AM Robert Landers 
wrote:

> On Wed, Nov 29, 2023 at 8:19 AM Stephen Reay 
> wrote:
> >
> >
> >
> > > On 29 Nov 2023, at 09:58, Larry Garfield 
> wrote:
> > >
> > > On Tue, Nov 28, 2023, at 7:49 PM, Juliette Reinders Folmer wrote:
> > >> L.S.,
> > >>
> > >> What with all the drives towards cleaner code, how do people feel
> > >> nowadays about `extract()` and `compact()` still being supported ?
> > >>
> > >> Both have alternatives. The alternatives may be a little more
> cumbersome
> > >> to type, but also make the code more descriptive, lessens the risk of
> > >> variable name collisions (though this can be handled via the $flags in
> > >> extract), prevents surprises when a non-associative key would be
> > >> included in an array and lessens security risks when used on
> untrusted data
> > >
> > > *snip*
> > >
> > >> I can imagine these could be candidates for deprecation ? Or limited
> > >> deprecation - only when used in the global namespace ?
> > >>
> > >> For now, I'm just wondering how people feel about these functions.
> > >>
> > >> Smile,
> > >> Juliette
> > >
> > > extract() has very limited use in some kinds of template engine, which
> use PHP require() as a template mechanism.  I don't think compact() has any
> uses.
> > >
> > > I very recently was just reminded that these even exist, as i had to
> tell one of my developers to not use them.  I think it was compact() he was
> trying to use.  I vetoed it.
> > >
> > > I would not mind if they were removed, but I don't know how large the
> BC impact would be.  They'd probably need a long deprecation period, just
> to be safe.
> > >
> > > --Larry Garfield
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: https://www.php.net/unsub.php
> > >
> >
> > Hi,
> >
> > While I think I understand the goal behind this, I think you're missing
> some factors here.
> >
> > Regarding use-cases for compact: the most common one I can think of from
> my work, is for passing multiple local variables as context to a logging
> function, but I'd be surprised if its not also used to build faux hash
> structures too.
> >
> > If your goal is to achieve an associative array (i.e a poor mans hash)
> of known variable names, using compact in php8+ has *less* risk of
> uncaught/unexpected errors than building it manually. Passing an undefined
> name (i.e. due a typo, or it just not being defined) produces a warning
> regardless of whether you build the array manually or pass the name(s) to
> compact(). Providing an array key name that doesn't match the variable name
> (e.g. due to a typo, or a variable being renamed) will produce no error
> when building the array manually, but will produce a warning with compact().
> >
> > IDEs (e.g. PHPStorm/IDEA+PHP plugin) can already understand that the
> names passed to compact are a variable name, and make changes when a
> variable is renamed via the IDE. They simply cannot do the same for plain
> array keys.
> >
> > Due to how variable scope works, the only way to re-implement compact()
> with the same key-typo-catching behaviour as a function in userland would
> be something that requires the user to pass the result of
> get_defined_vars() to every call.
> >
> > So no, I don't think compact() should be deprecated, what I think
> *should* happen, is to promote the current warning on undefined variables,
> to an error, as per
> https://wiki.php.net/rfc/undefined_variable_error_promotion. Whether this
> is a foregone conclusion or not, I don't know because that RFC doesn't
> mention compact() specifically.
> >
> >
> > extract(), as Larry points out has historically been used by 'pure php'
> style template systems, in a manner that's generally "safe". Personally I'm
> less inclined to use this behaviour now (i.e. I'd prefer to access named &
> typed properties from a template than arbitrary local variable names) but I
> don't think that's enough of a case to remove it, because just like with
> compact, by nature of how variable scope works, it's very
> difficult/impossible to re-implement this in userland, in a way that's
> reusable and doesn't involve using worse constructs (e.g. eval'ing the
> result of a function)
> >
> > I think there's possibly an argument to be made for improvements, such
> as changing the default mode of extract to something besides
> EXTR_OVERWRITE, or to have checks in place preventing the overwrite of
> superglobals.
> >
> >
> > Cheers
> >
> >
> > Stephen
>
> FWIW, I use compact all the time, usually like this:
>
> try {
>   // do stuff
> } catch(Throwable $exception) {
>   $this->logger->error("failed to do stuff", compact('exception'));
>   throw $exception;
> }
>
> But thanks for the reminder to finish the nameof RFC, I was waiting
> until after 8.3 to avoid the "trying to rush it to get into 8.3"
> shenanigans that happened to another RFC around the same time. If
> nameof passes, then it could make this more obvious when 

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

[Lynn]

On Mon, Oct 30, 2023 at 4:21 PM tag Knife  wrote:

> >
> > However, according to my example, the variable is defined and has its
> > value as 0 or false, and empty() returns true anyway. I confess that
> > I've had some problems like this, and we chose not to use empty(), as
> > sometimes 0 or false makes sense as a valid value.
> >
>
> That is exactly as the documentation explains it.
> empty is to check if a variable is not holding a usable value.
> 0, false, true are all valid values and show the variable is not
> empty.
>
> The purpose for empty is to check for undefined variables, empty
> arrays or empty strings.
> eg. "", [], null or undefined.
>

This is exactly where the problem lies. Is a string with just whitespace
empty? Why would an ArrayObject with count 0 not be considered to be empty
while an array with count 0 is? "empty" is subjective and therefore not a
reliable function to use. Especially in legacy code I find that people use
`empty` where they should've been using `count() === 0` and have resulted
in bugs that weren't discovered until months or years later. The variations
of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null` already
check all the scenarios you need, without risking funky bugs due to how the
internal check for "falsy" values works.

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

[Lynn]

On Mon, Oct 30, 2023 at 1:24 PM Alessandro Rosa 
wrote:

> Hi,
>
> I have posted a new RFC at this link
> https://wiki.php.net/rfc/empty_function
> where I suggested some improvements to the standard built-in empty()
> function and provided a number of examples.
>
> Thanks,
>
> Alessandro Rosa
> WEB : http://alessandrorosa.altervista.org
> LINKEDIN : https://www.linkedin.com/in/alessandro-rosa-9b7ba67b/


If anything I'd rather see `empty()` disappear, but I'll settle with a
warning to be cautious when using it. We don't need a replacement as you
should create your own function to validate what you consider "empty" or
not based on the given context and variable type.  For me `(bool) false or
"(int) 0" isn't empty either, it's still a value of sorts.

Re: [PHP-DEV] Custom object equality

[Lynn]

On Wed, Oct 18, 2023 at 2:51 PM someniatko  wrote:

> Hi internals,
>
> There is often a need to compare whether two objects are equal. For
> example, a popular [brick/money](
> https://packagist.org/packages/brick/money)
> library has a `Money` class, which has an `equals()` method. However, this
> becomes tedious to implement such methods, when multiple nested objects are
> involved. For instance, Money has an amount and a currency.
>
> There were already suggestions on the mailing list to allow "overloading"
> existing `==` operator, and some suggestions went even as far as
> overloading `<`, `>=` etc operators. However, overloading existing
> operators may lead to a BC break between the PHP version which does support
> the functionality, and which doesn't. It won't result in a BC break in case
> it's an entirely new syntax, because a library or a project won't be able
> to write code which overloads `==` in say PHP 8.4, but with code which
> still works in PHP 8.3 - it will have to require PHP 8.4+. But if it is
> implemented as a magic method, then `==` will work differently for 8.3 and
> 8.4.
>
> I suggest thinking about introducing a new operator `~=`, which signifies
> that custom equality is requested. In such a case,  `==` will work as it
> works now, and by default `~=` will work also like `==`, unless its
> behavior is overwritten via a magic method. If a magic method is not
> present in a class being compared, `~=` will compare two objects field by
> field, but using `~=` comparison rather than `==` comparison, recursively.
>
> For instance, a Money object may consist of Amount and Currency. If two
> Moneys are compared using `~=`, and Money does not implement a magic
> method, Amount also doesn't implement it, but Currency does, then Amounts
> are compared using  `~=` which is equal to `==` comparison in this case,
> but Currencies are compared using their custom comparison logic.
>
> This approach allows combining
> - no BC break - `~=` is a new syntax which is unavailable in older PHP
> versions
> - explicitly showing an intent that objects are compared using a custom
> comparison, rather than standard PHP one
> - allow to skip writing boilerplate equals() methods which just forward
> equals() to the nested objects
> - standardize such comparisons on the language level
>
> Of course how exactly this operator looks may be changed, `~=` is just an
> example.
>
> WDYT?
>
> Regards,
> Illia / someniatko
>

Note that `~=` is used in Lua instead of `!=`. Having this operator be an
overloading == would feel really counterintuitive to me. We have
"instanceof", and I've seen "is" ideas floating around. Could also look
into the direction of "equals" for this.

https://www.lua.org/pil/3.2.html

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

[Lynn]

On Tue, Oct 17, 2023 at 11:15 AM Robert Landers 
wrote:

> On Tue, Oct 17, 2023 at 11:10 AM Levi Morrison via internals
>  wrote:
>
> How is returning null any different than $array[0] on an empty array?
> https://3v4l.org/ >

> > c) Two such functions were proposed and rejected during the
> > array_key_first/last RFC
> > (https://wiki.php.net/rfc/array_key_first_last)
> >
> > Yes, that was in 2018. At that time, functions like str_contains() or
> > str_starts_with() wouldn't have even come into existence, just because
> > there was an obscure way to do it without them. I believe we've moved
> > on since then. Today we know how useful it is to use simple,
> > easy-to-understand methods, both for programmers who write and read
> > the code.
>
> It's true that sentiment may have shifted in this time. However, a
> common argument at that time still stands: `null` is not a good
> sentintenal for failure because the value inside the array very well
> could have been null. This is not true for the keys. For me
> personally, I think I would still vote no. I'm not entirely sure about
> that, but that's how I would lean right now.
>
> As it stands, you'd have to write code along the lines of:
>
> ```php
> $key = \array_key_first($array);
> if ($key === null) {
> // handle the failure
> } else {
> // success
> $value = $array[$key];
> }
> ```
>
> Yes, it would be slightly nicer if we could do:
>
> ```php
> $value = \array_first($array);
> if ($value === null) {
> // handle the failure
> } else {
> // success
> }
> ```
>
> But I fear in practice people will just omit the error checking.
>
> One way around that is to throw an exception. I'm not sure how I feel
> about that, but I'll think about it.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

> >K3gRs 
>
> Currently, it just outputs a warning, but the result is `null`.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I'm okay with `null` being given back as it's the current behavior of
accessing the key as well, which is often checked through `$array[0] ??
null`. Something like an `undefined` type could solve this problem, but
personally not a fan of this in Javascript. Maybe `array_has_first` or
something could be made, but honestly I would still just check for `null`
myself most likely.

Re: [PHP-DEV] Casing of acronyms in class and method names

[Lynn]

On Wed, Aug 30, 2023 at 1:44 PM Tim Düsterhus  wrote:

> Hi
>
> after suggesting the use of ucfirst(strtolower(...)) casing for acronyms
> within a classname of a draft RFC, I was made aware of previous class
> naming RFC (June 2017) that required the use of PascalCase for class
> names, with the exception of acronyms which must be completely uppercased:
>
> [...]
> 2. It decreases readability.
>
> Especially if multiple acronyms follow each other. One example is the
> PCGOneseq128XSLRR64 mentioned above: It's not clear that XSL
> (XorShiftLow) and RR (RandomlyRotate) are two different acronyms.
>
> Likewise PDOODBC is much harder to parse than PdoOdbc.
>
> Another example might be JavaScript's XMLHttpRequest which incidentally
> mixes both variants. According to the class naming RFC it would need to
> be called XMLHTTPRequest, resulting in 8 consecutive uppercase characters.
>

Thanks for bringing this up as readability is indeed an issue for me with
all caps acronyms. I would much prefer Acronyms to be treated as words as
this is how most people seem to use them anyway.

Re: [PHP-DEV] Apply strict_types to internal functions

[Lynn]

On Tue, Aug 29, 2023 at 2:46 AM Saki Takamachi  wrote:

> Hello.
>
> I’m Saki Takamachi.
>
> Inspired by the issue below, I'm thinking of proposing this RFC.
> https://github.com/php/php-src/issues/12055
>
> As the documentation below states, PHP's internal functions currently
> ignore strict_types.
>
> https://www.php.net/manual/en/language.types.declarations.php#language.types.declarations.strict
>
> I think the current spec is not intuitive,
> so I propose changing the behavior of the macro
> ZEND_ARG_USES_STRICT_TYPES() to allow internal functions to accept
> strict_types.
>
> I plan to make changes in zend_compile.h and zend_compile.c and do the
> changes myself, I haven't written any tests yet, but I'm thinking about
> making changes like this.
> https://github.com/SakiTakamachi/php-src/pull/1
>
> As per How To Create an RFC, I will first try to gauge response to this
> proposal on the mailing list.
>
> Thank you
>
> Saki Takamachi
>

Heya!

I was not aware that strict types didn't work here. While I'm 100% behind
the idea, I am afraid that changing this will break code in currently
strict files where the assumption was made that it already worked like
that. It would probably have to give deprecation notices first, and then
possibly a warning or removal in the next major to be feasible.

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

[Lynn]

On Wed, Jun 28, 2023 at 9:11 AM Nicolas Grekas 
wrote:

> > Also, I'm wondering whether it's worth the complexity to add support for
> > another magic method,
> > or would we be fine without this feature and its benefits? To put it
> > another way: how much
> > complexity is it worth to fix the problem of the wasteful deep cloning?
> > Does anyone have
> > an informed answer/opinion?
> >
>
> It's not only solving the problem of wasteful deep cloning, but also
> solving the problem of validating while cloning (the one Alexandru
> highlighted.)
> So yes, I think it's worth it. Also because to me shipping a solution with
> known shortcomings is likely going to turn into technical debt for the
> community and even for internals in the future.
>
> I saw your message about postponing this to 8.4. I think that's fair.
> Complex topic :)
>
> Nicolas
>

In terms of complexity, what if we could use property access hooks to
define how it should be cloned? I think this will cover a lot of scenarios
without having to think about the complexity of the clone function itself.
These hooks should probably be called _before_ the clone method called.

```php
 $value,
}

public MyValue $value {
// deep clone
clone => clone $value,
}

public readonly MyState $state = MyState::New {
// don't use either and mark it as not being constructed via "new"
clone => MyState::Cloned,
}
}
```

Re: [PHP-DEV] RFC [Concept] - Interface Properties

[Lynn]

On Sun, May 28, 2023 at 9:18 AM Nick Humphries  wrote:

> > I don't want to get into a debate about principles of OOP and design
> > practices, this list isn't the place for it. I don't want to sidetrack
> the
> > discussion. I suppose what an interface should conceptually be in PHP is
> > necessarily relevant to whether or not one supports this proposal,
> though.
>
> Agreed, I think the key question for this RFC to progress is "Should an
> OOP
> language interface support public properties".
>
>
Imo anything that's publicly visible in a class, should be publicly visible
in an interface.

Re: [PHP-DEV] PHP Package for PHP

[Lynn]

On Thu, May 18, 2023 at 3:07 AM Deleu  wrote:

> Hi folks!
>
> Reading through https://externals.io/message/120323#120326 and
> https://externals.io/message/120323#120332, it reminded me of a few times
> I've seen similar debates on internals about "why not do this on userland?"
> and the consensus seems to be inclined to only take the maintenance burden
> of internals function if there's strong justification for it regardless of
> whether there's consensus of being useful or not.
>
> Which begs the question of a PHP Package for PHP. Some benefits:
>
> - Written in PHP, it will allow a much wider pool of contributors than the
> scarce pool of C developers contributing to PHP source code.
> - Being official means it inherits the trust PHP already has
> - Green field development in this day and age often comes with a great set
> of automation tests that drastically lowers the maintenance burden
> - Possibility to standardize a lot of common code that has countless
> userland implementations
> - If we make a mistake of implementing a bad design, the worst thing might
> be that we "wasted" a good word in a function or class name. As long as
> test coverage is there we can probably just keep it running for many years
> with little negative impact other than "yeah, PHP did a bad job at X".
>
> Such a project could benefit from the RFC process already in-place and
> voters could take into consideration the lower maintenance burden when
> voting for something that they think it's useful.
> One relevant downside is that internals might get flooded with RFCs for
> filling up some common functionalities for a few years until it dials down
> a bit.
> It may also lead to re-discussing PHP's entire standard library.
>
> The work to get started seems to be about:
>
> 1- Getting an RFC to approve this idea itself
> 2- Getting a repository to host the PHP package code.
> 3- CI/CD
> 4- Release Management
> 5- Versioning Strategy
> 6- Package naming convention
> 7- Distribution strategy (single package vs multiple sub-packages)
> 8- PHP developers and community contributions
>
> Anything I'm missing? Thoughts?
>
> --
> Marco Deleu
>

A few more benefits:
 - an official php polyfill package to be forward compatible with new
classes/functions/constants for core php
 - popular features could eventually be ported to C if it gives a benefit
in performance, or if they are really popular
 - applications with slower upgrade cycles would have less effort
implementing new php features

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

[Lynn]

On Wed, May 17, 2023 at 4:54 PM  wrote:

> Hey,
>
> I have created on GitHub a feature request for a path_join function (
> https://github.com/php/php-src/issues/11258) and got the label that this
> requires a RFC. So I am here now :)
>
> The idea is to provide in PHP itself a function to join filesystem paths
> (idea: path_join) like in other languages, node as example (
> https://nodejs.org/api/path.html#pathjoinpaths). For me this function is
> some kind of base filesystem functionality like basename, realpath.
>
> Example usage:
>
> path_join('/base', 'my', 'path'); // /base/my/path
> path_join('/base', 'my', 'path', 'test', '..'); // /base/my/path
>
> Why not just string concatenation?
>
> When you concat just the paths you have to think about:
> - normalize string part to strip ending slash
> - for windows compatibility you have to use DIRECTORY_SEPERATOR
>
> I think this can improve the developer experience when working with
> filesystems a lot and people can delete their implementation.
>
> I am really looking for your feedback, right now I have no “karma points”
> to create a RFC in the wiki :)
>
> Thanks,
> Soner


I would like to have such a feature in php so I can ditch my own
implementation.

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

[Lynn]

On Mon, May 15, 2023 at 1:41 AM Hendra Gunawan 
wrote:

> 2. The shorthand notations supported (the shortest one) creates
> impaired syntax, and not pretty to look at for constructor property
> promotion.
>

It's starting to get crowded in object constructors. The following example
is so much more readable and maintainable imo. Would it be possible to
still add the quick assignment as a language feature? I'm personally not
happy having property definitions in both the class body _and_ the
constructor signature.

```php
class User {
private string $first;
private string $last;
public string $fullName {
get => $this->first . ' ' . $this->last;
set => [$this->first, $this->last] = explode(' ', $value, 2);
}

public function __construct($this->fullName) {}
}

// vs

class User {
private string $first;
private string $last;

public function __construct(
public string $fullName {
get => $this->first . ' ' . $this->last;
set => [$this->first, $this->last] = explode(' ', $value, 2);
}
) {}
}

// or

class User {
private string $first;
private string $last;
public string $fullName {
get => $this->first . ' ' . $this->last;
set => [$this->first, $this->last] = explode(' ', $value, 2);
}

public function __construct(string $fullName)
{
$this->fullName = $fullName;
}
}

```

Re: [PHP-DEV] Request for RFC Karma - Enum value semantics proposal

[Lynn]

On Fri, Apr 28, 2023 at 11:48 PM Garet Claborn  wrote:

> You are correct, thank you.
>
> The RFC draft has been posted to
> https://wiki.php.net/rfc/treat_enum_instances_as_values
>
> -Garet
>
>
I think this example should be "mixed" instead of "$mixed"? `public
function offsetGet($mixed $which){`

Maybe a bit of a side-track, what about an interface with a method that
lets an object specify what it would turn into if it were used as an array
key? In the case of enums that would mean they'd implement this interface
and just return the value. I hadn't seen this idea come by yet and I don't
know if it's a good idea, just something I was thinking of while trying to
group data objects based on a value. In theory this could also be done with
Stringable instead.

https://3v4l.org/Vi8kY#v8.2.5
```php
name;
}
}

$objects = [];
$data= [[1, 'Jane'], [2, 'John'], [3, 'Jake'], [4, 'Jane']];
foreach($data as [$id, $name]) {
$object = new MyObject($id, $name);
$objects[$object->toArrayKey()][] = $object;
// would turn into $objects[$object][] = $object;
}

var_dump($objects);
```

Re: [PHP-DEV] Introduction - SuitespaceRnD

[Lynn]

On Sun, Apr 23, 2023 at 1:23 PM Niels Dossche 
wrote:

> Hi
>
> Good luck with the RFC, I'm also quite interested in this feature so I'm
> interested to see where it goes.
> You might also want to explicitly ask for RFC karma so that you can create
> a wiki page for the RFC, if you haven't done that already :)
>
> Kind regards
> Niels
>

I am also interested to see where this goes, especially beyond the scope of
just enums.

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

[Lynn]

On Wed, Apr 12, 2023 at 10:14 PM Stanislav Malyshev 
wrote:

> Right. And participating meaningfully requires some level of commitment
> and investment. For example, willingness to familiarize oneself with
> some very simple rules and follow them. If that's not for you, that's
> fine - there are many other interesting things to do on the internet.
> But it's not a problem.
>

The rules and etiquette are detached from the mailing list, so it's not
obvious that they even exist.

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

[Lynn]

On Wed, Apr 12, 2023 at 9:36 PM Thomas Hruska 
wrote:

>
>
> This is the second major mailing list in the past few weeks that I'm on
> where this exact topic has arisen.  On the other list, the developers of
> the project were the ones who proposed it and the idea was universally
> and unilaterally rejected by all participants.
>
>
Was this topic discussed only on the mailing list? Asking mailing list
users if they like the mailing list is obviously going to skew the opinion
into a direction of people being in favor of the mailing list.

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

[Lynn]

On Wed, Apr 12, 2023 at 4:16 PM Rowan Tommins 
wrote:

> * Ease of access (is subscribing to e-mail *really* harder than logging
> into Github?)
>

Took me over a year and poking people on twitter before my mailing-list
sign-up worked, so I'd say that's a yes. I feel like this mailing list is
mainly a thing that works for people who have been using it a while and
have everything set up the way it works for them. Maybe I'm wrong, I just
don't consider the nature of mailing lists very accessible nor user
friendly.

In the end it seems to work for the current core contributors, not sure if
it works for future core contributors.

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

[Lynn]

On Wed, Apr 12, 2023 at 3:53 PM Alex Wells  wrote:

> What are your thoughts?
>

I'd simply give you a thumbs up and 100 reaction if I could, but instead
I'm giving everyone an unread notification just showing that I 100% agree.

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

[Lynn]

On Tue, Apr 11, 2023 at 3:33 PM Jeffrey Dafoe  wrote:

> > was something introduced in a time that the code being written using it
> has
> > 100% test coverage and static analysers protecting it. It's easier for
> me to deal
> > with any BC breaks of PHP 7.1 or higher than it is to deal with
> deprecations of
> > PHP 5.6 or lower.
>
> Essentially the same thing here. Removal of dynamic properties will be the
> next big one for my team. It's the deprecations that hit huge swaths of
> code without really offering much benefit that are annoying.
>
> -Jeff
>

You can add `#[AllowDynamicProperties]` to classes where you want to allow
dynamic properties.

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

[Lynn]

On Mon, Apr 10, 2023 at 1:45 AM Deleu  wrote:

>
> Unfortunately I couldn't find where, but I remember reading that PHP 7.2
> deprecation of non-countable types was one of the biggest "busywork"
> generator of the PHP 7 series. It made an extremely large impact at public
> and private projects across the world for something with questionable
> benefits.
>
> https://www.php.net/manual/en/migration72.incompatible.php#migration72.incompatible.warn-on-non-countable-types


I'm very thankful for fixes like this, it made us discover a lot of bugs in
a 20 year old product that we are still actively developing on.

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

[Lynn]

On Thu, Mar 30, 2023 at 10:04 AM Tim Düsterhus  wrote:

> Hi
>
> On 3/30/23 09:36, Rokas Šleinius wrote:
> >> 1) Please don't top-post.
> >
> > Am I doing it right now? I've never been on a mailing list.
>
> Yes. Ideally you would also cut the quoted parts to a minimum (like I'm
> doing here), but I believe the Gmail web interface doesn't make this easy.
>

Heya, I'm using the Gmail web interface and I think I haven't really
encountered major problems so far. Open the [...] below and you can split
and type underneath quoted parts. That said, mailing lists are ancient and
in my opinion a horrible way of doing things. 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, and most importantly you have to remind yourself
every time to press "reply all". 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. Email is also lacking edit buttons and integrated code
blocks like we're used to with github (or markdown in general). I don't
know how other projects deal with this though.

Re: [PHP-DEV] Methods which auto-return the class instance

[Lynn]

On Fri, Dec 23, 2022 at 10:33 AM Claude Pache 
wrote:

>
> ```php
> public function hit(): $this { $this->counter++; }
> ```
>
> Here, there is only one possible return value, and therefore the `return`
> instruction might be reasonably omitted.
>
> The real question is: Is it worth to add special cases for some specific
> return values?
>

We do have true, false, and null as return types (
https://www.php.net/releases/8.2/en.php#null_false_true_types). I'm
personally not opposed to having `$this` as return type, but it also starts
getting close to short function notations.

Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index

[Lynn]

On Tue, Dec 13, 2022 at 4:55 PM Thomas Hruska 
wrote:

>
> Not for those of us that run the package managed version of PHP in
> Ubuntu Server LTS it hasn't.
>
> https://wiki.ubuntu.com/Releases
>
> PHP 8.x is brand new as of *next year* from the perspective of those who
> patiently wait for certain OS level updates because overall system
> stability is important for critical production servers.  The x.x.2 for
> the Ubuntu LTS series tends to be sufficiently stable for most
> environments but 22.04.2 hasn't been released yet.  Hence my earlier
> comment.
>

Lagging behind like that is a choice though.

Re: [PHP-DEV] Re: Alias for `int|float`

[Lynn]

On Fri, Sep 30, 2022 at 11:04 AM Olle Härstedt 
wrote:

> 2022-09-29 5:08 GMT+02:00, Hamza Ahmad :
> > Hi Olle,
> >
> > I appreciate your idea of introducing a similar concept of typedef.
> > What if you write an RFC explaining that concept. I can join you
> > however in co-authoring this request.
> >
> > Seriously, I have had issues with writing such type again and again.
> > If you look at mixed type, it is indeed an alias of some union types.
> > Adding such an option to userland would lead to introduction of
> > various type hints. Plus, it will help devs write short hand aliases
> > for their intersection types.
>
> Note that my suggestion here is NOT about a project-global type alias,
> but an extension of the existing file-only alias, the use-statement.
> This can also explain the lack of reaction. :) Internal devs might
> already have consensus on the right way to proceed here, even if
> there's no RFC yet.
>
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I don't know if file based type aliases make sense, but just spitballing
some ideas here.
```
// core php or perhaps some libraries
typedef number = int|float;
typedef number = TypeDef::extend('number', static fn (number
$value, number $min) => $value >= $min);
typedef number = TypeDef::extend('number',
static fn (number $value, ?number $min, number $max) => ($min === null ||
$value >= $min) && $value <= $max);
typedef even = TypeDef::extend('number', static
fn (number $value) => $value % 2 === 0);
typedef positive = number<0>;
typedef negative = number;
typedef fraction = float<0, 1>;
typedef string = TypDef::extend('string', static fn (string
$value, int $min) => strlen($value) >= $min);
typedef string = TypeDef::extend('string', static fn
(string $value, ?int $min, int $max) => length_is_between($value, $min,
$max));
typedef regex = TypeDef::extend('string', static fn
(string $value, string $regex) => preg_match($regex, $value));

namespace  App\Domain;

typedef NonEmptyString = string<1>; // minimum length of 1
typedef LimitedString = string; // no minimum length, max length
of 32
// or typedef LimitedString = string; as alternative notation with
named parameters
typedef SomeToken = regex<'/a-z0-9{12}/i'>;

// only allows even numbers ranging from -100 to 100
function someFunction(even<-100, 100> $number) {}

namespace Elsewhere;

use  App\Domain\NonEmptyString;
use  App\Domain\LimitedString;
use  App\Domain\SomeToken;

someFunction(102); // fails `$max` check from `number`
someFunction(-99); // fails `% 2` check from `even`

```

I tried to use some consistency for the examples, by no means this is what
I think it must look like, just making sure the intent of the examples is
clear. This would be nothing more than syntactic sugar to what I'd
otherwise write in custom objects to validate types and values and ensure
type safety. This also doesn't take into account how operators should
behave or how autoloading could/should behave.

Re: [PHP-DEV] PHP 7.4.32 Released!

[Lynn]

On Thu, Sep 29, 2022 at 12:50 PM Yasuo Ohgaki  wrote:

> 2022年9月29日(木) 18:58 Derick Rethans :
>
> > The PHP development team announces the immediate availability of PHP
> > 7.4.32.
> >
>
> What happened to 7.4.31?
> Just curious why it's missing.
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net


The linked issues are also marked as private, or am I just a bit early
checking them?

Re: [PHP-DEV] [RFC] Asymmetric visibility

[Lynn]

On Sun, Aug 7, 2022 at 10:38 PM Rowan Tommins 
wrote:

> On 07/08/2022 11:54, Lynn wrote:
> > Reading "public private", "public protected", or "protected private"
> > reads really weird `public private(set) static self $property`.
>
>
> Interesting, it seems that you've unconsciously broken it up as "public
> private" followed by "(set)", rather than "public" followed by
> "private(set)". Perhaps it's because of the position of the parentheses,
> which do feel awkward to me at first glance. Would it read more
> naturally to you with different punctuation?
>
> public (private set) static self $property;
>
> Or:
>
> (public; private set) static self $property;
>
> Or:
>
> public private-set static self $property;
>

The more I think about it, the more I agree with Marco's point of view on
this. I don't think there's a way to add this functionality without it
looking confusing one way or another. Once I get to use php8+, I'll
probably end up using readonly for most code. I think the feature itself is
nice for the scenario where you want to have private or protected
mutability, but even this is a scenario I would avoid myself. I'm afraid
that based on the future possibilities `package(set)` will make it even
more confusing when allowing external modifications by specific classes,
which would make it even more complicated to find out who or what may or
may not modify a property from a reader perspective (like code reviews).

Re: [PHP-DEV] [RFC] Asymmetric visibility

[Lynn]

On Sun, Aug 7, 2022 at 12:34 PM Rowan Tommins 
wrote:

> Can you expand on where you think the ambiguity / implicitness is? As I
> understand it, the RFC is proposing exactly three new combined access
> levels:
>
> - "public private(set)"
> - "public protected(set)"
> - "protected private(set)"
>
> Although aesthetically it will take a bit of getting used to, it seems to
> me pretty clear that the first means "mostly public, but private if you
> want to set it", and so on.
>
> The only thing I can think of that could be described as "implicit" is
> that accessing a property by reference is considered a "set" operation,
> which I'm not sure how any implementation could avoid.


Personally for me it's the syntax. Reading "public private", "public
protected", or "protected private" reads really weird `public private(set)
static self $property`. In the end it makes sense if you know what it
means, otherwise it's probably confusing. I really like this RFC and I feel
like this might just be the way to go forward, but I have my doubts about
how many more keywords can be realistically added before it becomes a
problem.

Re: [PHP-DEV] [RFC] [Under Discussion] Random Extension Improvement

[Lynn]

On Mon, Jun 20, 2022 at 3:15 PM Guilliam Xavier 
wrote:

> Hi,
>
> > https://wiki.php.net/rfc/random_extension_improvement
>
> Thanks, but I am not sure about your argument in "Classnames are not
> canonicalized": does "PHP applies strict PascalCase to class names"
> (which remains to be proved) really imply to rename *acronyms* (e.g.
> "CombinedLCG" to "CombinedLcg")? especially given existing classes
> like "SimpleXMLElement" (not "SimpleXmlElement"), and that the
> accepted "Class Naming" RFC (https://wiki.php.net/rfc/class-naming)
> voted for "PascalCase except Acronyms" (not "Always PascalCase") --
> excerpts:
>

Not specifically directed at this discussion, but perhaps this needs a
revision. HTTPStatus is much harder to read for me than HttpStatus and it's
unclear where the boundary of an acronym starts or stops. If anyone ever
decides to make an RFC for this, you have my vote. These Acronyms are
treated as words and thus should follow the same naming convention. If they
shouldn't be treated as words, write their full name:
HypertextTransferProtocolStatus.

Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements

[Lynn]

Good timezone!

On Thu, Jun 16, 2022 at 11:44 PM Pierrick Charron  wrote:

> About making a "Good OOP API", of course the goal is to make a *Good* OOP
> API. But there are things to take into consideration. The proposal here is
> yes to expose the new Curl URL API which is quite small, but also to modify
> the existing curl API to make it a little bit more digest for developers.
> Good or bad the existing ext/curl is here and will continue to exist for
> quite some time. It was designed (maybe on purpose or not) to be a low
> level API with tons [1] of low level features, and it was clearly designed
> as a thin wrapper/bridge over libcurl. I mean the fact is currently each
> constant is the exact same one as in libcurl, and each function is a
> wrapper over the exact same function in libcurl. Is it OK to have one part
> that is a thin wrapper and another part that is a "remodeling" of the API ?
> (This is not a rhetorical question, I really ask myself the question).
>

I'm not a C developer, and the only other place I've ever used cURL is on
the command line. I honestly care very little for it resembling whatever
the C library is, as C is a different language with no OOP. The procedural
API for cURL is really annoying to deal with, and I think it would be worth
designing an OOP counterpart. I think most of this would go into a new
design for setting options among things, as a list of constants with
possible values is one of the worst ways to have to configure something in
my opinion. I know that both the Symfony Http Client and Guzzle are popular
libraries, perhaps design wise they could serve as an inspiration?

I'm personally not too experienced with cURL nor the level of details that
go into http libraries, but I do see this as an opportunity to make a
really good implementation from scratch. In my opinion it's worth spending
some time on this.

Larry said:

Like most of the responders so far, I would say skip the procedural API,
> just go OOP and be done with it.
>

I'm okay implementing one last feature in the procedural API if it's really
desired to have this functionality, especially if this is beneficial for
security and reduces bugs. The reason being is that even if we have the
best possible OOP library for cURL, every single procedural API would
benefit from this change without having to completely rewrite their
implementation, which will be a problem if the OOP interface isn't just a
1:1 copy into object form. That said, we should avoid having: cURL
procedural + cURL procedural in objects + cURL OOP. Having 2 different
object based libraries to do the same thing PHP is confusing and will just
end up in way too many Stack Overflow questions.

Perhaps it is best to split this into 2 separate RFCs?

Regards,
Lynn

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

[Lynn]

On Mon, Mar 14, 2022 at 8:04 PM Mike Schinkel  wrote:

>
> Variable variables provide functionality[1] that if removed would force
> major rewrites of PHP applications that were architected in a way that
> depends on that functionality.
>
And while probably between 90% and 99% of the time when someone uses
> variable variables there are better alternatives, variable variables make
> certain code possible that would be impossible without them.
>

Do you have examples where this is the case? Using arrays is a compatible
replacement as far as I know, and I highly doubt these kinds of hacks are
necessary.

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

[Lynn]

On Sat, Mar 12, 2022 at 3:11 AM BohwaZ  wrote:

> This RFC is confusing two different things:
>
> 1. variables inside strings (options 1, 2, 3)
> 2. dynamic variables names (option 4)
>
> The 4th one is very useful.
>
> $v = ${'param_' . $name};
>

Please don't ever ever ever write code like that!


> There is no other practical way to do that, so removing that feature
> would mean breaking something useful with no replacement.
>

While it's still a problematic way of writing code, you can use arrays
instead:
`$v = $something['param_' . $name] ?? null;

This at least keeps all the issues to the scope of `$something`.


> Also why break something that works and is used?
>

Variable variables should be removed from PHP asap. It's 2022 and I still
encounter bugs due to this "working" in legacy applications.

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

[Lynn]

On Fri, Mar 4, 2022 at 9:17 AM Kalle Sommer Nielsen  wrote:

> Den fre. 4. mar. 2022 kl. 01.18 skrev Lynn :
> > Not making a statement is also making a statement.
>
> I disagree, assuming a stance without understanding the context is insanity
>
>
What context are we not understanding?

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

[Lynn]

On Thu, Mar 3, 2022 at 10:46 PM Kalle Sommer Nielsen  wrote:

> Den tor. 3. mar. 2022 kl. 20.29 skrev Eugene Sidelnyk  >:
> >
> > BTW, regarding symfony and banner, it doesn't seem to have many (if any)
> > issues in github flooded. So what's the problem?
>
> The problem is making a political statement. This is not something the
> PHP project does; you may think that it means the PHP project doesn't
> care and that is in your right to do so. However it is not the place
> for PHP to make a statement on this matter, nor is it on other
> matters. You are welcome to promote this on your own social media
> platforms and websites.
>

Not making a statement is also making a statement.

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

[Lynn]

On Wed, Mar 2, 2022 at 10:31 AM Victor Bolshov 
wrote:

> Hello internals.
>
> In these dark days for humanity, we as people of civilization, people
> of sanity, kind and caring people with children and families - we have
> to speak up, loud and clear, in support for Ukraine. To stop Russian
> aggression.
>
> I suggest to add Ukranian flag and a supportive anti-war disclaimer to
> the header of php.net website.
>
> Why is this important? There are a lot of PHP developers in Russia. A
> lot of them, sadly, have been brainwashed by Putin's propaganda. They
> still must have a lot of respect to PHP authors and creators. Seeing
> that these people, who have their respect, are against the war and for
> the freedom of Ukraine, might have an impact.
>
> This is not the time to "stay away from politics", we are experiencing
> an attack on humanity itself. Take example from
>  and their clear statement.
>
> Say NO to war!
>

+100, Symfony has also added a banner on the front page that links to
https://symfony.com/blog/symfony-stands-with-ukraine

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

[Lynn]

On Mon, Feb 7, 2022 at 9:35 AM Mark Randall  wrote:

> 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.
>
> The changes you propose are not something that I am comfortable with
> either.
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>

I agree with this sentiment. I rather see solutions that solve null values
being passed to these functions instead. The in-house legacy framework I
use has a small array wrapper that through `ArrayAccess` ensures `null` is
returned instead of a notice/warning being thrown when accessing a key that
does not exist. During `offsetGet` it will return itself wrapped around the
value if it's an array. I'm not saying that this is a good alternative for
the problem, it's just one of the solutions that can be taken to tackle
issues with `$_POST` and `$_GET` access for example.

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

[Lynn]

On Sat, Jan 29, 2022 at 8:58 PM Christian Schneider 
wrote:

> 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.
>

To stay with the car analogy: Seatbelts were once considered unnecessary as
well.

Just because you know for sure you know you mean what you wrote, doesn't
mean everyone else knows. They have to read the code you didn't write to
know for sure.

On Wed, Jan 26, 2022 at 7:16 PM Christian Schneider 
wrote:

> Am 26.01.2022 um 18:37 schrieb Lynn :
> > I don't understand how variable initializers are considered boilerplate
> and make it easier to read without.
>
> [off-list as I think this has been discussed before]
>
> Example:
>
> function count_words($words)
> {
> foreach ($words as $word)
> $counts[$word++];
>
> return (array)$counts;
> }
>
> vs.
>
> Function count_words($words)
> {
> $words = [];# <-- Boilerplate
> foreach ($words as $word)
> {
> $counts[$word] ??= 0;   # <-- Currently worse boilerplate
> but beside your point
> $counts[$word++];
> }
>
> return $counts;
> }
>
> I find the first version easier to understand but I guess we'll have to
> agree to disagree here.
>
> Regards,
> - Chris


I would appreciate it if you keep the replies to the mailing list. Though
while I'm at it, your examples are why it's important that we have PHP to
let us know when things are broken.

You're not going to convince me that not initializing variables is a good
thing, I've had to fix way too much code where that kind of cowboy coding
was at fault. As a reader I cannot see if the lack of a variable
initialization is intentional, so I have to go through the history of the
file to verify this behavior, and then I add the initialization so the next
developer seeing this won't have to waste a lot of time by doing the same.

A huge amount of changes in PHP are based on what other languages do (or
sometimes rather don't). With the amount of the web that PHP powers, it's a
good thing that PHP grabs the good bits and improves itself. Ensuring that
variables are properly initialized is one of them, as it protects the
developers from making preventable mistakes without requiring external
tools.

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

[Lynn]

On Fri, Jan 28, 2022 at 3:13 PM Robert Landers 
wrote:

> I would posit differently. In my experience in upgrading code, it was
> mostly intentional.
> Here's an example:
>
> 
> if($doThing) {
>   $doOtherThing = maybe();
> }
> // later
> if($doOtherThing) {
>   doOtherThing();
> }
> ---
>
> There's no bug here, nothing is unintentional, and the intent is clear.
> Now,
> if we want to get rid of the warning we need to say $doOtherThing = false
> before getting to the first if-statement, but should this halt everything
> in
> production? I don't personally think so and it would be undesirable for it
> to do so.
>

 Let me go over this.

> There's no bug here, nothing is unintentional, and the intent is clear

I cannot guarantee there's no bug, I cannot guarantee that this is
intentional, and the intent is certainly not clear. I can't tell whether or
not this code is suffering from a merge conflict, and I cannot guarantee
that whatever type `maybe();` returns here works. If at some point the
return type of `null` is changed to `false`, while the assumption of
undefined is `null`, passing `false` to a nullable typed argument later on
will break.

> Now, if we want to get rid of the warning we need to say $doOtherThing =
false before getting to the first if-statement

Thank you for pointing to the example above. `null` and `false` are
different values. Your assumption here is that setting it to `false` would
fix the problem, but the actual value would've been `null` and changing it
to `false` might actually break more.

> but should this halt everything in production? I don't personally think
so and it would be undesirable for it to do so.

Any type error should if you ask me. Unexpected types cause unexpected
behavior, and the longer PHP will try to continue with assumptions of types
and implicit casting, the bigger the damage can be. All this type juggling
is headache material and the less I see of it, the better.

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

[Lynn]

On Wed, Jan 26, 2022 at 5:35 PM Christian Schneider 
wrote:

> 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.


Projects that are not being actively developed, nor being improved to work
with newer php versions shouldn't block the future of PHP.

On Wed, Jan 26, 2022 at 5:35 PM Christian Schneider 
wrote:

>
> 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.
>

How do you determine that a missing variable initializer isn't a bug or
broken merge? I encountered this as recently as yesterday. It's easy to
miss, hard to find out what the actual code is supposed to be doing while
you're digging through your commit history. Especially when working on
bigger applications with more contributors this can lead to a serious
issue. Luckily the bug I fixed didn't have any big implications, but it
could've just as easily been a mistake costing thousands of euros.

I don't understand how variable initializers are considered boilerplate and
make it easier to read without. It makes things unclear and unpredictable,
and can unintentionally change behavior of your code when not being
cautious. Considering "easier to read" is being taken quite literally here,
I'll change it to "easier to understand". When in the future, either
tomorrow or in 5 years, a developer reads my code, the last thing that
developer wants is to make assumptions of how the code is supposed to work
when things are seemingly missing.

That said, my focus is on variables. Imo index initializers are part of a
bigger discussion that encompasses (dynamic) data structures and shouldn't
be treated the same.

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

[Lynn]

On Wed, Jan 26, 2022 at 3:48 PM Christian Schneider 
wrote:

> 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.
>

Far too often I encounter code where I don't know if it was a variable with
a typo, a bad merge, or simply incrementing an undefined variable,
especially in the context of legacy code. It leaves me with a lot of
guessing and side-tracking when trying to find bugs or make changes. Yes
this can be enforced by static code analysis, but quite frankly getting
tired of having to fight for this in many projects that don't use it. It's
much, much harder and costs much more effort to have to convince a whole
lot of people all the time of something being better, and having to rely on
blog posts that people *might *read. My experience is that people don't
care for these rules and recommendations if they are opt-in and in fact
make it harder to implement.

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.

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

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

[Lynn]

On Thu, Jan 13, 2022 at 10:04 AM Tim Düsterhus, WoltLab GmbH <
duester...@woltlab.com> wrote:

> Hi Lynn
>
> On 1/12/22 9:30 AM, Lynn wrote:
> >   I was thinking more of a "keep track of the values replaced, and in the
> > end purge all those values from the end-result" kinda thing.
> >
>
> Thank you for the clarification. This still is not in scope, because I
> believe that to be harmful, as the parameter redaction will be
> completely unpredictable.
>
> Consider a sensitive parameter that is of type '?string', i.e. nullable.
> Now with your proposal, whenever 'null' is passed to this parameter, all
> 'null's within the stack trace would be hidden, even if they are
> completely unrelated.
>
>
Yeah I'm with you 100%, this has more edge cases than I originally thought
of. The RFC as it is already improves a lot for me so I'll be glad to see
it regardless!

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

[Lynn]

On Wed, Jan 12, 2022 at 9:17 AM Tim Düsterhus, WoltLab GmbH <
duester...@woltlab.com> wrote:

> Hi Lynn
>
> On 1/11/22 11:23 AM, Lynn wrote:
> > One possible addition; would it be possible to analyze the masked values
> > and mask any 100% matches elsewhere?
>
> No, this is not in scope for this RFC, as it would require accurate
> tracking of variable contents across reassignments and possibly function
> calls.
>
> My understanding is that this basically would require support for
> tainted variables, i.e. this very old RFC: https://wiki.php.net/rfc/taint


 I was thinking more of a "keep track of the values replaced, and in the
end purge all those values from the end-result" kinda thing.

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

[Lynn]

On Mon, Jan 10, 2022 at 3:05 PM Tim Düsterhus, WoltLab GmbH <
duester...@woltlab.com> wrote:

> Hi Internals!
>
> this is a follow-up for my "Pre-RFC" email from last Friday, January, 7th.
>
> Christoph Becker granted me RFC editing permissions and I've now written
> up our proposal as a proper RFC:
>
> https://wiki.php.net/rfc/redact_parameters_in_back_traces
>
> I recommend also taking a look at my previous email:
>
> https://externals.io/message/116847


Heya, thanks for this RFC!

The product I work on provides integration with dozens, if not hundreds of
remote services. This can be anything from mailboxes, (S)FTP(S), HTTP, and
we have a lot of databases for our tenants. Being the legacy code it is,
it's a never ending battle to not expose critical information to the end
user. Even though I've been working here for several years now, I still
keep finding these things occasionally. As we also use external logging
tools (such as the ELK stack), we want as little critical information sent
anywhere and this RFC seems to really help reduce the leaking of this
information here. In the ideal scenario the connection information minus
the password is logged explicitly, so that I have the information available
whenever one of the many tenants systems failed to connect to one of the
many dynamically configured APIs, but doing this retroactively through
millions of lines of code that's over 10 years old is a lot of work.

One possible addition; would it be possible to analyze the masked values
and mask any 100% matches elsewhere?

https://3v4l.org/G0RaQ
```
function one(string $param) {
throw new Exception($param);
}

function two(#[SensitiveParameter] string $param) {
one($param);
}

two('the secret');

Fatal error: Uncaught Exception: the secret in /in/G0RaQ:4
Stack trace:
#0 /in/G0RaQ(8): one('the secret')
#1 /in/G0RaQ(11): two('the secret')
#2 {main}
  thrown in /in/G0RaQ on line 4
```

This would help in the scenario where the function `one` comes from an
external library, but it also means that I don't have to go through every
single layer and add the attributes. In the above example I want any
mention of `the secret` to be hidden. Let's say the sensitive data is a
password, then I don't want that password shown at all in the stacktrace.
The original RFC is already very valuable to me without this, but would
still expose a lot of sensitive data I fear.

The result I want from this:
```
Fatal error: Uncaught Exception: Object(SensitiveParameter) in /in/G0RaQ:4
Stack trace:
#0 /in/G0RaQ(8): one(Object(SensitiveParameter))
#1 /in/G0RaQ(11): two(Object(SensitiveParameter))
#2 {main}
  thrown in /in/G0RaQ on line 4
```

This would also cover cases where for some reason the sensitive data is
added to the exception. Yes, this big facepalm is something I encounter
sadly too often in legacy code.

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

[Lynn]

On Thu, Dec 30, 2021 at 5:54 PM Vincent Langlet <
mr.vincent.lang...@gmail.com> wrote:

> Would you still consider this as a massive BC break if
> - The type of the key don't change anymore i.e. array_search(0, ['10' =>
> 0]) will be '10' and not 10.
> - $array[10] still return $array[10] ?? $array['10']
> - $array['10'] still return $array['10'] ?? $array[10]
>
> so it still cast the value when accessing to an array key, but when using
> array_keys/array_search/array_flip/... it won't be cast anymore.
>

"Would you still consider this as a massive BC break"

Yes, because `'10'` from an array flip is not `10` anymore, which means
that using any strict comparisons on those values afterwards will fail if
they assumed it was an int.

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

[Lynn]

On Wed, Dec 29, 2021 at 4:42 PM Vincent Langlet 
wrote:

> Hi,
>
> I recently discovered that an array was automatically casting
> numeric-string keys to int if it was possible. For instance, the following
> array:
>
> $a = ['01' => '01', '10' => '10'];
>
> Is not an array with the key '01' and '10' but instead consider the second
> key as an int.
>
> This has some implications like the fact that
> - array_flip(array_flip($a)) !== $a
> - array_search('10', $a) is an int when array_search('01', $a) is still a
> string. Someone using strict types and passing the result to a function
> expecting a string could end with an unexpected crash.
>
> I've created an issue about this
> https://github.com/php/php-src/issues/7845
> but it was recommended to me to send a mail to this mailing list instead.
>
> I don't think this behavior should be considered as "normal" and would like
> to propose to change this for PHP 9, as it's a BC-break. To me it can and
> be considered as a follow-up of
> https://wiki.php.net/rfc/string_to_number_comparison and
> ttps://wiki.php.net/rfc/saner-numeric-strings
> . This is still a
> "concept"
> since I never code with C and know nothing about the PHP implementation and
> if this change would be possible. Any help is welcome then.
>
> Thanks
>

Hi,

While I'd love for this inconsistency to go away, I also know that this is
most likely such a big change that it causes months of work and broken code
because it relies on this behavior. It wouldn't surprise me if this
singular change would cause more work than all previous BC breaks combined.
This behavior is documented: PHP: Arrays - Manual


The key can either be an int or a string. The value can be of any type.
>
> Additionally the following key casts will occur:
>
>- Strings containing valid decimal ints, unless the number is preceded
>by a + sign, will be cast to the int type. E.g. the key "8" will actually
>be stored under 8. On the other hand "08" will not be cast, as it isn't a
>valid decimal integer.
>- Floats are also cast to ints, which means that the fractional part
>will be truncated. E.g. the key 8.7 will actually be stored under 8.
>- Bools are cast to ints, too, i.e. the key true will actually be
>stored under 1 and the key false under 0.
>- Null will be cast to the empty string, i.e. the key null will
>actually be stored under "".
>- Arrays and objects can not be used as keys. Doing so will result in
>a warning: Illegal offset type.
>
>

Re: [PHP-DEV] [RFC] !instanceof operator - reaction measuremen

[Lynn]

On Mon, Dec 13, 2021 at 12:19 PM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

>
> Why not "not" instead? The "!" in front of "i" in "!implements" is almost
> not visible which IMO could get easily ignored unintentionally.
> Instead constructs like "$foo not implements stdClass" have higher
> visibility and are currently a syntax error.
>
> Cheers,
> Michał Marcin Brzuchalski
>

Definitely a good idea! I was considering suggesting that as well when
writing the implements/extends down, but wasn't sure if that would be
doable as it would introduce a new keyword as well if I understand the
setup of php correctly.

Re: [PHP-DEV] [RFC] !instanceof operator - reaction measuremen

[Lynn]

Heya,

While I definitely agree with this, and after more than 10 years of PHP I
still have the tendency to write `if ($object !instanceof MyClass)` anyway.
Would it be possible, or would it collide with constants to do the
following?
```
$object === MyClass;
$object !== MyClass;
```
The reason I'm hoping this would be possible, is that I often have brainlag
trying to write "instanceof" and I either make several typos, or I end up
with "instance" and it takes me an error message to realize I forgot the
"of". The "instanceof" is counterintuitive for me compared to operators.

If this isn't possible and `!instanceof` would be adopted, what about the
following in addition to the proposed example?
```
$object implements MyInterface;
$object !implements MyInterface;
$object extends MyClass;
$object !extends MyClass;
```

On Mon, Dec 13, 2021 at 11:53 AM Oliver Nybroe 
wrote:

> I would like to create my first RFC proposing adding a new operator
> `!instanceof` named `T_NOT_INSTANCEOF`.
>
> The purpose of this RFC is to add syntactic sugar for checking if an object
> is not an instance of something else.
> The current syntax for checking not instance of looks the following way
> ```php
> !$object instanceof MyClass
> ```
> When I read this I read it as:
> Negate the `$object` variable and check if that is an instance of
> `MyClass`.
>
> My proposed operator would allow for the following syntax
> ```php
> $object !instanceof MyClass
> ```
> This is for me and people I have spoken to a much clearer syntax.
>
>
> Some arguments on other ways the not instance of can currently be written
> ```php
> !($object instanceof MyClass) // Wrapping in parenthesis
> ! $object instanceof MyClass // Simply adding spacing
> ```
> My main problem with these alternative syntaxes is the readability when
> added inside an `if` condition
> ```php
> if(!($object instanceof MyClass)) { ...
> if(! $object instanceof MyClass) { ...
> ```
> compared to
> ```php
> if($object !instanceof MyClass) { ...
> ```
>
>
> In regards to implementing the feature, I wouldn't mind trying to do that
> myself. I believe this change is relatively simple in the parser and AST
> and something I should be able to figure out.
>
>
> What do people think about this? Would love to clarify if needed.
>
> Best regards
> Oliver Nybroe (he/him)
>

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Lynn]

On Tue, Nov 16, 2021 at 1:23 PM Pierre Joye  wrote:

> On Tue, Nov 16, 2021 at 4:11 PM Lynn  wrote:
> > What is the point of this change if it's an opt-in? Projects that are
> still relying on dynamic properties today and "have no time" to fix them
> now, won't have time in 3 years either. Please let us have nice things
> today instead of years from now :)
>
> If it is an opt-in (like Larry proposes f.e.), you will have them
> today as well.
>
>
Just to be clear, are you talking about opting in to having the
deprecation, thus adding it to every single class in my code base, and
every new class added in the future? Or are you talking about opting in to
enabling dynamic properties? Because the first makes it pointless to have
while the latter makes this a great RFC.

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Lynn]

On Tue, Nov 16, 2021 at 4:52 AM Pierre Joye  wrote:

>
> My vote will change to yes as soon as the change is an opt-in instead of an
> opt-out for the 8.x lifetime.
>
>
What is the point of this change if it's an opt-in? Projects that are still
relying on dynamic properties today and "have no time" to fix them now,
won't have time in 3 years either. Please let us have nice things today
instead of years from now :)

Re: [PHP-DEV] [RFC] Allow null as standalone type

[Lynn]

On Tue, Oct 5, 2021 at 4:08 PM Côme Chilliet  wrote:

>
> Why would function a(): null|false {} be legal but function b(): null|0
> would not?
>
> This is inconsistent to me. And adding null, then false, then true for the
> sake of completeness feels like avoiding to treat the static value as type
> hint subject.
>

I'm not opposed to having values that aren't objects. Feels like a
shorthand notation of enums, or the subset thereof.

```php
function getType(): 'dropdown'|'textfield';
function getExitCode(): 0|1|255;
```

Re: [PHP-DEV] Allowing `(object)['key' => 'value']` in initializers?

[Lynn]

On Mon, Sep 27, 2021 at 3:15 PM Sara Golemon  wrote:

> I think for consistency's sake, we'd want to provide a base constructor to
> stdClass to take an associative array that maps into dynamic properties,
> e.g.
>
> class stdClass {
>   public function __construct(array $props) {
> foreach ($prop as $name => $val) {
>   $this->$name = $val;
> }
>   }
> }
>
> Then you could:
> php>  static $x3 = new stdClass(['key' => 'value']);
>

If the structure of `$something = {};` would ever be allowed in PHP, the
following could be done instead: `$something = { ...$array };`. This will
reduce the dependency on the stdClass.

Re: [PHP-DEV] Proposal: Shorthand initialization and destructuring of associative arrays

[Lynn]

On Mon, Sep 27, 2021 at 11:27 AM Konrad Baumgart  wrote:

> I was recently developing with js/ts and I liked the ease of returning
> multiple items from a function as an object, while still preserving
> their name.
>

I recently encountered this as well in Typescript. I believe the syntax is
something like this?
```js
const someProperty = "something";

const foo = {
someProperty,
anotherProperty: "Something else",
};

// same as
const foo = {
someProperty: someProperty,
anotherProperty: "Something else",
};
```
Obviously this won't work with PHP arrays, which is probably why you
decided for `=> $someProperty`.

I'm a big no-no when it comes to `compact()` and `extract()`. These
functions make my life hell. Despite knowing what they do, it still takes
me a lot of reading to try and figure out what they do. Even now I will
have to go to the documentation to understand exactly how either of them
work. Renaming a variable in a certain scope should not break something
outside of that scope, and I see this as a big problem in the proposal.
When I take your example, spot the error that will cause everything to
break runtime with limited static analysis to let you know (hint: missing a
g in the first variable).
```php
return [ => $dailyAgregations, => $weeklyAggregations];
```
Refactoring tools could just ignore the outside scope and automatically
change it, yet this won't solve anything for text find and replace.
```php
return [
'dailyAggregations' => $theNewVariableName,
=> $weeklyAggregations,
];
```

If something like this were to be introduced, I'd happily see it happen
with anonymous objects and interfaces accepting properties:

```php
interface DashboardAggregations
{
public readonly array $dailyAggregations;
public readonly array $weeklyAggregations;
}

function getDashboardData() : DashboardAggregations
{
$dailyAggregations = [];
$weeklyAggregations = [];

// ...
return {
$dailyAggregations,
$weeklyAggregations,
};

// same as
return {
dailyAggregations: $dailyAggregations,
weeklyAggregations: $weeklyAggregations,
};

// same as (if properties in interfaces were allowed)
return new class($dailyAggregations, $weeklyAggregations) implements
DashboardAggregations {
public function __construct(
public readonly array $dailyAggregations,
public readonly array $weeklyAggregations,
) {}
};
}
```
If you then really need the destructuring, you could do something like this
(just a random syntax chosen), though I'd still be in favor of leaving this
aside as you now have a nice object with properties that are accessible.
```php
{$dailyAggregations, $weeklyAggregations} = getDashboardData();
```

This way php could verify the return value with the return type, and static
analyzers can determine the structure of what's to be returned. Imo this
functionality is not worth the headache with arrays.

That said, it feels like this proposal is more of a tuple/multiple return.

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

[Lynn]

On Mon, Sep 6, 2021 at 5:28 PM Nikita Popov  wrote:

> What do people think about adding such an alias? Is this worthwhile?
>

What if `DynamicObject` becomes an interface instead of an alias? In the
future `stdClass` could be deprecated and replaced by anonymous classes
using the `DynamicObject` interface to prevent manual initialization. I
feel like renaming (this seems to be the end-goal) will not solve some of
the problems that `stdClass` brings to php. Hamza Ahmad brought the
interface up in the other thread: https://externals.io/message/115800#115806
.

```php
// core php
interface DynamicObject { /* ... /*}

// in case of removal, legacy support could be kept as
class stdClass implements DynamicObject {
use DynamicObjectTrait; // perhaps also core php?
}

// a library wants a DynamicObject for whatever reason?
final class MyCustomDataObject implements DynamicObject {
public function __get(string $name) : mixed {
// as a developer I now have full control over where
// this data comes from and is stored internally
}
/* ... */
}
```

To me it feels like making this an interface gives PHP more flexibility in
dealing with this in the future. One intermediate step could be to turn
`stdClass` into an interface that extends `DynamicObject`. 8.2 could
deprecate manual instantiation of `stdClass`, meaning that in 9.0 it could
be removed as class and turned into an interface, reducing the need to
update code relying on the `stdClass` types. `get_class` would still return
`stdClass` in 8.x and thus not break when using a `DynamicObject`.

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

[Lynn]

On Wed, Sep 8, 2021 at 5:38 PM Mike Schinkel  wrote:

> A couple more things; add a `JSON_OUTPUT_DYNAMIC_OBJECT` flag to output to
> DynamicObject for `json_decode()`,  add a 3rd parameter for flags to
> var_export() for the same reason, a `'return_dynamic_object'` option for
> `unserialize()`, and so on.
>

It would also be interesting to enter a user-defined class here to work as
a reversed JsonSerializable. Could be a static factory method for all I
care, and would omit the requirement of serialization libraries for
"simple" things where you still want decent object typing. Could also work
together with interfaces accepting properties, effectively making the
result of json_decode an anonymous class that still adheres to an
interface. In case of the custom 'deserialization' you can throw exceptions
if the format is not correct. In the case of an anonymous class with an
interface it could throw an exception if the structure doesn't match
(possibly controlled by flags?).

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

[Lynn]

On Thu, Sep 2, 2021 at 10:27 AM Kevin Lyda  wrote:

> PHP has a stat cache which is... unfortunate. As noted in this bug from
> 2004[0] it causes a number of issues for PHP users and is irrelevant
> in modern operating systems. Heck, it's not even useful in OS's people
> might consider ancient at this point.
>

I have had to add clearstatcache in the past, and probably having a bunch
of places where this should be added and isn't yet causing subtle and hard
to find bugs, I welcome this option.

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Lynn]

On Wed, Aug 25, 2021 at 12:03 PM Nikita Popov  wrote:

> This RFC takes the more direct route of deprecating this functionality
> entirely. I expect that this will have relatively little impact on modern
> code (e.g. in Symfony I could fix the vast majority of deprecation warnings
> with a three-line diff), but may have a big impact on legacy code that
> doesn't declare properties at all.
>

The project I maintain is massive and it's full of code that implicitly
defines properties. As long as the deprecations are clear, I'm 100% behind
this proposal as it will finally give me leverage to fix the code base at
some point in time.

Re: [PHP-DEV] [RFC] User Defined Operator Overloads

[Lynn]

On Mon, Aug 23, 2021 at 4:03 PM Pierre  wrote:

>
> Anyway, I always thought that __set, __get __call and __invoke should
> have been banned a long time ago.
>

Considering I use __invoke on a daily basis as it makes life so much easier
when you have single method (service) classes, I'm going to disagree on
this one. The other functions are also very useful tools to migrate legacy
code.

I agree that not being able to click through to operator overloading
methods is annoying, untraceable __toString is the worst. I do think that
this is something IDEs can handle, though not sure how reviewing will be
when diffs still hide the implementation.

Re: [PHP-DEV] [RFC] Never For Argument Types

[Lynn]

On Sun, Aug 15, 2021 at 1:11 PM Jordan LeDoux 
wrote:

>
> So your intuition is correct. `foo(never $something)` will result in a
> `TypeError` if you try to call it directly. The only way it can be called
> is by being overridden with a wider type, which is why most of the focus is
> around inheritance. Technically, you *could* use it in a function and that
> would make the function uncallable, because any function with a parameter
> of type never is uncallable unless it is overridden and widened.
>
> This is in line with type theory for how bottom types work in other
> languages as well.
>
> My biggest worry about using something besides `never` is that it *is* the
> bottom type already. It's only usable in return types, but within the
> engine it *is* the bottom type. That's what the bottom type in a type
> system generally means: this can't be used and/or the program stops if this
> is used. If we made a bottom type for returns (which we have), and then
> made a *different* bottom type for arguments, we'd be in a situation that
> is unique in programming languages as far as I can tell. I have done a bit
> of research into this as part of the RFC, and I haven't found a single
> language with multiple bottom types. :/
>
> TypeScript, Elm, and PHP have the bottom type `never`. Ceylon, Kotlin, and
> Scala have the bottom type `Nothing`. Rust has the bottom type `!`,
> JavaScript with Closure Compiler annotations has `!Null` (which is intended
> to mean a non-null member of the null type), Julia has `Union{}`, Python
> has `typing.NoReturn`, and Lisp has `NIL`.
>
> None of them (so far) have multiple bottom types for different
> circumstances.
>
> And the meaning of the type isn't *exactly* "any". It's more like "none".
> But the type `string` contains the "none" concept also. You take "none" and
> then you add the parts that make a string type to "none", and what you're
> left with is just the string type. That's why it can be broadened to
> anything, because *all* types contain `never`, just like you can subtract 0
> from any integer.
>
> I have been focusing on the use cases, which are about how this interacts
> with widening and inheritance. But the type itself I would argue is fully
> descriptive where it is defined: that code can never be called due to the
> type on the parameter being never. It must be inherited. If we did
> something like `any`, that would indicate that the intent for inheritance
> more clearly, but think about the code it's actually defined in. If you had
> the following code:
>
> ```
> class A {
>   public function doSomething(any $var): string {
>   }
> }
> ```
>
> Would you expect calling that method to result in a `TypeError`? Because
> that's what *should* happen. The code it is actually written in cannot
> accept `any` type, in fact it can `never` accept a type.
>
> Jordan
>
>
So the `never` just tells the developer "extend/implement me with a type",
that makes sense to me. Having multiple bottom types (and thus most likely
aliases) would probably make it even more confusing, you're right that this
is probably the best course of action 

Re: [PHP-DEV] [RFC] Never For Argument Types

[Lynn]

 On Sat, Aug 14, 2021 at 1:27 AM Jordan LeDoux 
wrote:

>
> Any feedback is greatly appreciated.
>

https://github.com/JordanRL/never-argument-type


My only feedback is that it should not be called `never`. If I see `never`
as the parameter type, I read this as never being allowed to pass anything,
which means that `foo('something')` with `foo(never $something)` will
result in a compile error. The type `never` only makes sense from a return
type perspective: "Should it return? never". Perhaps `any` or `anything`
makes more sense? I've also seen a suggestion to name it `abstract`, and
maybe there are more suggestions I've missed. To me it also sounds like the
goal of `never` as a parameter type is different from the return type. From
my understanding one indicates that a type is required, while the other
indicates that nothing ever returns, giving it the same name is confusing.


Apologies for sending this message twice to you Jordan, reply to all is not
my default reply button.

Re: [PHP-DEV] Problems with the mailing list [was: Re: [PHP-DEV] Request for karma to vote on RFCs]

[Lynn]

On Tue, Jul 20, 2021 at 10:50 AM Bruce Weirdan  wrote:

> On Tue, Jul 20, 2021 at 10:45 AM Lynn  wrote:
> > I'm also still receiving a bunch of messages from
> > the mailing list in my spam folder (gmail), and there's not much I can do
> > about it.
>
> I fixed it in Gmail with a filter like this:
> Matches (goes into 'Has words' field): list:(internals.lists.php.net)
> Do this: Never send it to Spam
>
>
> --
>   Best regards,
>   Bruce Weirdan mailto:
> weir...@gmail.com


Thanks!! I've added the filter, let's see how it goes

Re: [PHP-DEV] Problems with the mailing list [was: Re: [PHP-DEV] Request for karma to vote on RFCs]

[Lynn]

On Tue, Jul 20, 2021 at 9:33 AM Peter Bowyer 
wrote:

> I have now been contacted by 2 people who tried multiple times to join this
> mailing list and cannot.
>
> It took me 5 weeks for my signup to work. During that time I emailed the
> different @php.net mailboxes related to infrastructure and/or the web and
> received no response. Eventually I managed to sign up - once I created this
> brand-new Gmail account. The signup form is unreliable.
>
> There are people wanting to take part in discussions who can't.
>
>
It took me a very long time to get signed up to the mailing list as well,
so I poked around on twitter back then to see if anyone could help me. I've
tried several times over the timespan of at least a year and I never
received a follow up after using the form. I'm not sure what changed, it
just worked eventually. I'm also still receiving a bunch of messages from
the mailing list in my spam folder (gmail), and there's not much I can do
about it. I would love to see a system replacing the mailing list, one
where we can reliably use things like markdown to properly quote and have
code blocks and have at least semi-decent threaded discussions.

Re: [PHP-DEV] Request for karma to vote on RFCs

[Lynn]

On Mon, Jul 19, 2021 at 11:47 AM Kalle Sommer Nielsen  wrote:

> Why is it then fair to give them voting rights if they only contribute
> their vote but not words before hand? Why is it only possible to give
> feedback in terms of a +1 or -1 and not feedback in text form? Because
> if its only possible in that way, it makes me think that it is purely
> a PR thing which makes me worry that the power vested into the voter
> may not be just.
>

Currently there are people with voting permissions that do vote, yet do not
interact with RFCs or the mailing list. Regardless of the reasons one may
have for wanting to vote, the requirements given should be applied equally
if this is the argument.


> Why is there no dialogs from their side on internals with problems
> they may have with directions? So far I do see a few faces from the
> community like representives static analyzers, Nicolas Grekas and
> Marco Pivetta to name some who actively takes part of the challenges
> at hand and even actively runs RFCs on their own with implementation
> patches, which is fantastic and well deserved in my opinion.
>

Yes, and I love it when I see new users interact with the mailing list,
even when in the end the questions or arguments changed nothing to the RFC.
It shows that people are probably invested. How do you measure investment
behind the scenes though? How often has someone decided to not post
anything on the mailing list because after testing a bunch of changes
proposed, it worked and required no comment? Would every user that one day
would want to have voting rights post a "yes I agree" message in every
thread in order to show they contribute in discussions? Sometimes when I
see a change proposed, I will jump into 3v4l or my `php -a` and test if a
proposed change would work or break anything for an edge case I came up
with. Proposals and changes pretty much always work so I don't reply or
comment, this investment (for lack of better words from my side) can't be
measured.

I would personally be interested in knowing how much work Tobias does
behind the scenes to ensure proposed changes and RFCs work with code run by
thousands, if not millions of developers.

Re: [PHP-DEV] Request for karma to vote on RFCs

[Lynn]

On Mon, Jul 19, 2021 at 10:33 AM Pierre  wrote:

> Le 19/07/2021 à 10:11, Lynn a écrit :
> > A vast majority of proprietary code depends on open-source community
> > written by the community.
>
> All your arguments are good ones, even if in my position I don't agree
> with everything. Nevertheless, I specifically don't agree with this one:
> a lot of proprietary code _uses_ open-source community code, but is not
> always tied to it. You're ignoring all projects that took the other
> direction, clean architecture, business libraries, dependency-free code,
> and others, whose goals are not to be dependent upon third party, but
> rather integrate with them in the software stack edges, making it both
> replaceable and discrete. I don't write "Symfony" projects, I write
> business domain projects, Symfony only brings a nice dependency
> injection container and a router I could both replace easily.
>

Hence I wrote "A vast majority". Even if it's not your code directly, your
application has a dependency on open-source php software that is often
directly impacted by every decision voted on for php, whether this is
Symfony, Pimple, Laravel or any other dependency injection you've decided
to integrate. If you choose to use abstractions, then I think it's only
fair to have the authors of those abstractions have a say in changes that
impact their abstractions, whether it directly impacts the "end developer"
or not.


> In my use case, focusing on my code is what primarily matters, and I'm
> not denying language changes are impacting for open source software, but
> I trust PHP for always keeping its BC promise (and it does, probably
> thanks to "In fact, open-source package maintainers are often one of the
> first lines when it comes to PHP compatibility"), which at least resolve
> that.
>

I fully agree with this, as a developer I do not want to worry about low
level php changes that do not directly impact me. Therefore I think that
people who do get impacted by this (for example open-source package
managers), at least get a vote in these changes. It's unfair to put the
burden of writing abstractions on someone and then tell them they don't get
a say in making their lives easier or more difficult.

---

Other than that, polling with the community to see if an idea can get
traction before more proposing it on the mailing list or through an RFC is
always a good idea in my opinion.

Re: [PHP-DEV] Request for karma to vote on RFCs

[Lynn]

On Mon, Jul 19, 2021 at 9:41 AM Pierre  wrote:

>   - For once, I'm writing PHP since PHP 3, and doing it professionally
> for more than 15 years, I wrote PHP code 8+ hours a day for the latest
> 15 years (more or less), I'm one of the many silent users for which each
> language feature change will impact every-day's life. Maintaining open
> source community driven tools doesn't make their writers fundamentally
> better than the rest of us in programming, it just make them visible.
>

I use php every day, I have been doing so for close to 10 years now.
Language features also impact my daily life, and I'm glad they do. The
software Tobias writes also has a big impact on my daily life, just like
PHP as I depend on a lot of his packages. Voting rights doesn't make
someone a better developer, and applying for them for this reason makes no
sense to me. Working with this many packages in the PHP ecosystem means
that one (hopefully) has a lot of experience in a lot of parts of
open-source software. In fact, open-source package maintainers are often
one of the first lines when it comes to PHP compatibility. They ensure your
software keeps working because they keep their packages up-to-date. Every
minor change in PHP can cascade into having to update hundreds of packages.
Every choice made can seem good for certain use-cases, and then completely
fall apart when someone with this much experience brings a good argument to
the table.

   - All those daily silent users doesn't always agree with community

> packages standards, style, design and direction, and that's legit, thus
> community maintainers cannot represent all the daily users. Regarding a
> community package, no matter how much it relies on community or users
> and feedback, will always see its final decisions under the hand of a
> few, which may not be representative (and for the best, since that the
> maintainer will have to maintain it, it's only legit to let him/her them
> decide).
>

They cannot and do not represent all the daily users. At best they decide
that a certain standard is worth keeping and (hopefully) ensure things like
consistency through the ecosystem. This can be seen through composer and
PSR autoloading for example.


>   - Proprietary code represents much more code in the end that
> open-source, most of us write proprietary all day long, at least as much
> code as we re-use community code.
>

A vast majority of proprietary code depends on open-source community
written by the community.

---

I think that people who have a big impact on the ecosystem should be able
to vote. Perhaps it would be an idea for other voters to vote on whether or
not others can receive voting rights? When someone contributes a lot of
(free) time to the ecosystem and makes a big impact, I think it's unfair to
ask for even more (free) time to make a direct contribution to PHP just to
get voting permissions, it feels like this is just for show.

Re: [PHP-DEV] Type casting syntax

[Lynn]

On Mon, Jul 12, 2021 at 10:36 PM Mike Schinkel  wrote:

>
> In your hypothetical view here, what happens when the $container does not
> have SomeService to provide?  Does it throw an Exception?
>
>
Up to the developer that implements it. If the signature would be
`get(?string $id): T;` then I would assume an error should be thrown by
PHP, or an Exception by the method, or handled by the developer to always
return `T`. `?SomeException` as `T` could let the developer not throw an
exception if needed and return `null` instead.

Re: [PHP-DEV] Type casting syntax

[Lynn]

On Mon, Jul 12, 2021 at 10:20 PM Mike Schinkel  wrote:

> It seems you have just illustrated why in reality we really do not need
> type casting/assertions in PHP given its current features, because we
> already have what we need.
>

That's not an argument I agree with, as it would invalidate the need for
short closures, null coalesce, constructor property promotion, etc.

Continuing on the previous example:
```php
$service = $container->get(SomeService::class);
assert($service instanceof SomeService);

// could be replaced with
$container->get();

// or in case of multiple instances:
$container->get('the.service.alias');

// perhaps the service is optional
$container->get();
```

Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.

[Lynn]

On Wed, Jun 30, 2021 at 11:03 AM Guilliam Xavier 
wrote:

> PS: "amusingly", the code samples are hard to understand after rendered on
> https://externals.io/message/115213


I'd expect a lot of markdown issues when trying to write examples using
backticks. While such a thing might not be blocking for a nice language
feature, it will surely impact the tooling in the ecosystem for
documentation. I already run into issues with single line code examples in
Discord because it gets messy real fast. Sure it's just an annoyance, but I
would like to suggest avoiding it if we can.
```
`const something = `foo`;`
```

Re: [PHP-DEV] Proposal: clamp

[Lynn]

On Wed, Jun 23, 2021 at 3:07 AM Marco Pivetta  wrote:

> The problem is exactly the fact that it is trivial to implement in
> userland: why not do it there instead?
>

My 2cents: because people won't use it when the barrier is too high to get
it. There are a ton of great libraries that have functionality like clamp,
and some more elaborate, like an array replacement. In the end -based on my
experience- people go to the php documentation and look for functions that
they can use, or they use their IDE autocomplete functionality to see
what's hinted at. Having these functions spread through the ecosystem means
discoverability is low. I've needed the "clamp" function in the past and
didn't even consider looking for a library to do this for me. Why would I
even install a library to have a single function anyway? It feels like a
massive overhead. I've seen coworkers use funky SPL functionality I didn't
even know existed to avoid using external dependencies that have already
solved their problem in a neat way, which were in fact already installed
through composer. They found the solution through google and ended up in
the official php documentation.

I'd love to see these small additions in the core, they make the language
feel more complete. The fact that they are easy to implement in userland
means that we can have great forward compatibility through polyfills and
already start using them in codebases that haven't been upgraded yet to the
latest PHP version. I've been very happy to have been able to use
str_starts_with, str_ends_with, and str_contains in 7.3, as they came in
with a generic php polyfill.

With a "see also: clamp" in the min/max function documentation, this would
be easy to find as well.

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

[Lynn]

On Tue, May 25, 2021 at 11:31 AM Hans Henrik Bergan 
wrote:

> fwiw this can be implemented in userland, and i bet someone already made a
> composer package for it ^^
>

Not everyone is interested in doing `$array = new
ArrayWrapper($originalArray)` and then breaking all `array` parameters.
There are a bunch of different packages and people prefer different
packages on top of that. Some packages will have feature X and others will
have feature Y, and that makes it even harder to properly use. The downside
of having this in PHP will obviously be that it's much less flexible than a
userland implementation. I'd be very happy to see it in PHP while I won't
even bother looking for array wrappers in userland.

On Tue, May 25, 2021 at 12:05 PM someniatko  wrote:

> There is Pipe Operator RFC existing already, which most probably would
> suit your needs. The code you want will look like this:
> https://wiki.php.net/rfc/pipe-operator-v2
>
> ```php
> $array |> array_map($somefunction).
> ```

The pipe operator feels like a poor solution while `->` would do exactly
what people want.

On Tue, May 25, 2021 at 12:05 PM someniatko  wrote:

> > I was wondering whether $array->map($somefunction) would be possible.
>
> There is Pipe Operator RFC existing already, which most probably would
> suit your needs. The code you want will look like this:
> https://wiki.php.net/rfc/pipe-operator-v2
>
> ```php
> $array |> array_map($somefunction).
> ```
>
> Best wishes,
> someniatko
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Partial function application

[Lynn]

On Sun, Apr 25, 2021 at 9:26 PM Larry Garfield 
wrote:

> Greetings, Internalians!
>
> I would like to offer for your consideration another RFC, specifically
> syntax for partial function application.
>
> https://wiki.php.net/rfc/partial_function_application
>
> It includes an implementation by Joe Watkins that is already about 95%
> complete.  (There's some edge cases he's still sorting out, but all of the
> typical cases should work already.)  Most of the design work comes from
> Levi Morrison and Paul Crovella.  I helped out with the tests, a few edge
> bits, and general instigator/nudge. :-)
>
> Discuss.
>
> --
>   Larry Garfield
>   la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Heya, this is an interesting feature!

The way I understand it, it adds the ability to turn a call to an object
method into a callable?
```php
class CategorizedThings {
private array $theThings = [];
public function addOneThing(mixed $thing, string $category): void {
$this->theThings[$category] = $thing;
}
}

$things = new CategorizedThings();
$adder = $things->addOneThing(?, 'a category');

foreach ($repository->findAll() as $aThing) {
$adder($aThing);
}

// which would be the same as:

$things = new CategorizedThings();
$adder = function (mixed $aThing) use ($things) {
$things->addOneThing($aThing, 'a category');
}

foreach ($repository->findAll() as $aThing) {
$adder($aThing);
}
```

I assume the following would also be possible?
```php
class Something {
public static function toString(mixed $v): string {
return (string) $v;
}
}

function toString(mixed $v) : string {
return (string) $v;
}

array_map(Something::toString(?), [1, 2, 3]);
array_map(toString(?), [1, 2, 3]);
// instead of
array_map([Something::class, 'toString'], [1, 2, 3])
array_map('toString', [1, 2, 3]);
```

If this is indeed the scenario, would it be worth adding a syntax to
indicate _all_ parameters can be placeholders? When a signature has
multiple arguments, `toString(?, ?, ?, ?)` could become `toString(...?)` or
maybe something like `toString(*)`?

Re: [PHP-DEV] Re: Proposal: namespace the SPL

[Lynn]

On Thu, Feb 11, 2021 at 6:55 PM Levi Morrison via internals <
internals@lists.php.net> wrote:

> I don't know the answer to that question. However, I don't think we
> should add a deprecation on the very first version that we add the
> aliases anyway. I think that would make for a bad upgrade experience
> from 8.0 to 8.1. I would leave that more for 8.3, 8.4-ish in the
> release cycle so there are at least a few versions for people to
> organically change their code without triggering any notices of any
> kind.
>

I would very much prefer this to be deprecated in the same version. This
way you prevent the confusion of which of the two to use and have people
implement the one we already know is going to be removed. Deprecations do
not make it a bad upgrade experience at all. Quite the opposite in my
opinion, they hint to me nice and early on which parts of the code base I
have to adjust. The earlier the better.

Re: [PHP-DEV] PHP 8 release announcement page on php.net

[Lynn]

On Mon, Oct 12, 2020 at 9:57 AM Roman Pronskiy 
wrote:

> Hello Internals,
>

Hi, this message ended up in my spam directory with the message, could be
that people missed it. When opening the message, gmail told me: "Gmail
could not verify that it actually came from jetbrains.com. Avoid clicking
links, downloading attachments, or replying with personal information."

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

[Lynn]

On Mon, Oct 5, 2020 at 12:00 PM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:

> Yes, "use (*)" is perfect!
>
> With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
>
> Michael Voříšek
>
> On 5 Oct 2020 11:57, Andreas Leathley wrote:
>
> > On 04.10.20 22:08, Rowan Tommins wrote:
> >
> >> If we added an opt-in syntax for "capture everything", we might
> >> instead write this:
> >>
> >> $f = function() use (*) {
> >> $x = $y = $z = null;
> >> }
> >>
> >> Without re-initialising all local variables, we would no longer be
> >> able to know if they were actually local without looking at the
> >> surrounding scope for a value that might be captured. I am unconvinced
> >> by this trade-off of opt-out instead of opt-in.
> >>
> >> One use case I've seen proposed is closures which capture a large
> >> number of variables; I would be interested to see an example where
> >> this is the case and is not a "code smell" in the same way as
> >> requiring a large number of parameters.
> >
> > Something like "use (*)" seems like a great enhancement to me. I often
> > use a wrapper function for SQL transactions, something like:
> >
> > ```php
> > public function update(int $numberId, int $addressId, bool $isMainNumber
> > = false): void
> > {
> > $this->transaction->run(function () use ($numberId, $addressId,
> > $isMainNumber): void {
> > // Do all SQL queries for the update
> > });
> > }
> >
> > ```
> >
> > In these cases there is a lot of redundancy because of having to import
> > the variables, and if a variable is added, it has to be added in two
> > places in a slightly different way. The following would be much nicer:
> >
> > ```php
> > public function update(int $numberId, int $addressId, bool $isMainNumber
> > = false): void
> > {
> > $this->transaction->run(function () use (*): void {
> > // Do all SQL queries for the update
> > });
> > }
> >
> > ```
> >
> > This would also increase code readability.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php


How should php deal with the scenario where you want to `use` everything
and have one variable by reference?

```
function () use (*, &$butNotThisOne) {};
```

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

[Lynn]

On Tue, Sep 1, 2020 at 9:31 AM Nikita Popov  wrote:

> To be in line with naming conventions, I would suggest calling these
> iter_any() and iter_all(), using iter_* as the prefix for our future
> additions to the "functions that work on arbitrary iterables" space.
> iterable_any() and iterable_all() would work as well, though are
> unnecessarily verbose.
>
> Regards,
> Nikita
>

Hi,

I would very much prefer the verbose versions of the two, "iter" doesn't
mean much to me, and I can imagine it's confusing to newer developers as
well. I'd rather not have to guess what it means when reading it, as it
could also mean something I've never heard of. Though if the choice arises,
I would prefer "any" and "all" over "iterable_any" and "iterable_all" for
the sake of simplicity.

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Lynn]

On Tue, Aug 11, 2020 at 3:03 PM Theodore Brown 
wrote:

> A second downside of @[] that doesn't appear to have been discussed
> yet is typability. On my keyboard, it requires four different keys
> on different sides of the keyboard, whereas @@ just requires two keys.
>

If typability really matters, we should've deprecated the backtick version
to run things. We also seem to forget about readability. @@ makes things
really hard to read for me as it draws attention, the same goes for <>
being written as such, with spaces it's fine. In terms of @[] typability,
my IDE auto completes the ] when I type [. After that we have to type a
word which will most likely require keys on the right side of the keyboard
anyway. Sure, typing @@ is easier, for me this is at the cost of
readability. I read code more frequently than I write it, so I think this
should matter more.

Please don't use @@ for annotations/attributes.

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Lynn]

On Tue, Aug 4, 2020 at 4:19 PM David Rodrigues 
wrote:

> Suggestions:
>
> $(Attribute()) (available)
> $[Attribute()] (available)
> <> 2)>> (like strings escapes)
>

The syntax for the first two seems oddly pleasing when used within PHP.

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Lynn]

On Wed, Jul 22, 2020 at 2:39 PM Deleu  wrote:

> "Terrible" is the amount of humans having their lives taken by a pandemic.
> This is at most slightly inconvenient for you. The aggressive tone in this
> discussion is extremely unnecessary.
>

Hi,

If you want to get nitpicky about the definition:

adjective: *terrible*

   1. 1.
   extremely bad or serious.
   "a terrible crime"

I agree with the above posters that @@ for annotations is a terrible
syntax. My choice (if I could vote) would also be the rust variant.

Regards,
Lynn

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

[Lynn]

On Thu, Jun 18, 2020 at 3:38 PM Bob Weinand  wrote:

> P.s. And to be honest, I've never heard from a dark-skinned person that
> they felt actually oppressed by words like blacklist.
>
> And here my personal opinion, to be taken with a grain of salt: This whole
> white- and blacklist discussion is mostly "hey I want to make black people
> feel more welcome, let me call blacklist bad and condemn everyone not
> agreeing. Then I have done my good deed" - without having any actual impact
> on the well-being of dark-skinned people. - That's what it feels like for
> me, but I'm open to being corrected by those who are actually dark-skinned
> and impacted by it, in which case I'll immediately retract my last sentence.
>

Hi Bob,

Nobody is talking about oppression when it comes to certain "technical"
terms. Please look my post from earlier and look at the tweets I link:
https://externals.io/message/110515#110574

I can recommend everyone to expand their bubble, as a lot of replies in
here show that the bubbles are homogeneous.

Regards,
Lynn

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

[Lynn]

On Tue, Jun 16, 2020 at 10:09 AM Peter Bowyer 
wrote:

>
> So if we want to do this, let's:
>
> 1. Ask the black community what they find offensive in PHP
> 2. Listen
> 3. Prioritise the responses and judge which are feasible to act on
> 4. Act
>

This points out the obvious, people are stuck in their own bubble because
Black people _have_ been telling us. The past week I've seen quite the
amount of posts in regards of the github main branch change. Here are some
I saw come by recently:
 - https://twitter.com/techgirl1908/status/1272683477620502531
 - https://twitter.com/roniece_dev/status/1272636145520848896
 - https://twitter.com/mimismash/status/1272619723050622976
 - https://twitter.com/zkat__/status/1272603164454162432

There's a variety of opinions and not everyone agrees that it's something
that must be changed. However, I'm getting the feeling that there's a fair
amount of people who do want to see this changed, and not just to be
"politically correct". As someone linked this on github, I will link it
here as well: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6148600/

"bUt WhAt AbOuT bLaCkHoLe?" - Stop trolling, there's no negative
connotation with this.

It is a decidedly political claim that long-time industry standard term
> with established neutral meaning is suddenly "harmful". And I really
> resent the implication of "the color of our skin means you don't get to
> have an opinion on this topic" that was made here.
>

It's not "suddenly harmful", people have been speaking up about this for
years, they were simply ignored because the majority are white cishet males
who don't care.

> As white men, we're being dismissive, insensitive and strongly suggesting
> > we don't want change. While people may not feel offended by any of these
> > terms being discussed, this thread alone already serves as reason for
> > people to feel like there's no room for diversity in the internal
> community
> > of php.
>
> The "we" in this is extremely biased, it attempts to force me to feel
> as an inferior human (to steal the term from Larry above), because I
> do not agree with your request for a change. The classification you
> just did there is something I personally would feel offended by,
> because you attempt to use my ethnicity as an argument for why I feel
> the way I feel.
>

Because white cishet men are treated like inferior people in the
development world /s ... This is not an attempt to make you feel "inferior"
at all. People are (rightfully) pointing out that white people have no say
in what Black people should or should not feel about this. Technical
challenges are no reason to block social progression.

Regards,
Lynn

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

[Lynn]

On Mon, Jun 15, 2020 at 7:46 PM Alain D D Williams 
wrote:

> It is very easy to take offence when none is meant at all. One needs to
> look at intent.
>

Hi,

I'm going to disagree here. It's not about intent, it's about impact. You
can have the best intentions with the worst results.

When I read the replies here, it makes me sad. The comments come from a
place of white privilege and I'm sad to see that's how people think about
it.

Regards,
Lynn

Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Lynn]

On Thu, Jun 11, 2020 at 10:45 AM AllenJB  wrote:

>
> This could be either as:
>
> a) Character count (at line 456, character 23)
>
> b) Quote either the remainder or the parsed section on the line (MySQL
> quotes the remainder, for example)
>
> c) Quote the whole line with an indicator where the error occurred. I'm
> not sure what the best way to do this would be - generically this could
> be encapsulated in several values: The line content, token start
> character count, token length / end character count
>

I really like the combination of A + C. After using php for 13 years the
error messages are still a bit cryptic at times, especially in legacy code
where you have a gazillion warnings in your IDE.

Regards,
Lynn

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Lynn]

On Tue, Jun 9, 2020 at 1:55 PM Benjamin Eberlei  wrote:

> Larry's suggestion about #[Attr] makes an important argument about allowing
> to declare attributes in code in PHP 7 in a forward compatible way that has
> not been brought up before.
>
> /** @ORM\Entity */
> #[ORM\Entity]
> class User {}
>
> This code would work on PHP 7 and 8.
>
> The #[] syntax would have about equally low breaking potential as @@. It
> would be the same syntax as Rusts, and close to C++/C# syntax.
>

Hi,

The idea of making annotations forward compatible in php7 this way has a
big + from me. I honestly don't mind the syntax too much. How would
multiline notations work with this?

#[ORM\Entity(
arg1,
arg2
)]

This notation would obviously break in php7. Would it be possible (in this
case) to do something like the following example? This would have php7 not
care because they are comments, while php8 could filter the # out and make
it a valid annotation.

#[ORM\Entity(
#   arg1,
#   arg2
#)]

I'm also okay with having everything on a single line, just wanted to point
out this might cause issues.

Regards,
Lynn

Re: [PHP-DEV] [RFC] Named arguments

[Lynn]

On Tue, May 5, 2020 at 8:22 PM Nikita Popov  wrote:

> Anyway. Your point that named arguments expand the API surface has been
> acknowledged. I don't think this issue is really avoidable, it's a rather
> fundamental trade-off of named parameters. I do think you're a bit quick in
> jumping to conclusions. It's not like this problem doesn't exist in
> (nearly) every language supporting named arguments.
>
> There are some things we can do to mitigate this though. One that we
> recently discussed in chat is to allow methods to change parameters during
> inheritance, and allow named arguments to refer to the parameter names of
> the parent method as well. Renaming parameters in a way that causes
> conflicts (same parameter name at different position) would cause an LSP
> error. I'm not entirely convinced this is the best approach yet, but this
> does address some concerns (including the "interface extraction" concern
> you mention on reddit).
>
> Another is to allow specifying the public parameter name and the private
> parameter variable name separately, as is possible in Swift. This would
> allow changing "parameter" names arbitrarily, without breaking the public
> API. This would be a pretty direct counter to your concern, but I'm not
> really sure that your concern is important enough to warrant the additional
> weight in language complexity. I've never used Swift myself, so maybe this
> is actually awesome and I just don't know it.
>
> Regards,
> Nikita
>

Hi,

If I understand this correctly, something like this could be done?

```
// current version, argument name = "firstArgument"
function example(string $firstArgument) {}
// name changes, bc can be kept, argument name = "firstArgument" and
"argument"
function example(string firstArgument: $argument) {}
```
This would make it possible to keep backwards compatibility, and perhaps
even trigger a notice when called with the old name?

Regards,
Lynn

Re: [PHP-DEV] [RFC] Mixed type

[Lynn]

On Fri, Apr 24, 2020 at 2:12 PM Bob Weinand  wrote:

> Mixed is in almost every case just patching the holes in PHPs type system.
> And as such, I'd rather promote RFCs trying to properly fix the gaps in the
> type system than supporting mixed.
>
> Mixed is a hack, do not use mixed.
>

Heya Bob,

I maintain lots of legacy code and I cannot add return types despite being
truly mixed. Mixed is not a hack, it's a scenario that frequently happens.
There are lots of use-cases where we explicitly want to mark it as such as
it truly accepts anything. Would I use it in new code? Pretty much never,
as `string|int` would already cover the majority of cases, especially where
ints are represented by strings.

I would love to see mixed being added as it lets me remove a lot of
docblocks that are only added so I can indicate mixed. I disagree that it's
patching holes, it's filling a gap that's currently missing something.

Regards,
Lynn

Re: [PHP-DEV] Typed callable properties

[Lynn]

Heya,

Fairly off-topic, just so you're aware. This message arrived in my spam
folder, just like some other messages always do. I get: "pair.com did not
encrypt this message", which I see come by quite often. A lot of messages
from Ilija also ended up in my spam folder and so it did for others. I'd
imagine people will have missed this message.

Regards,
Lynn

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Lynn]

Hi,

> In this case, the problem with COPA as proposed is that it only works for
> public properties that are assigned literally.  That is, in my experience,
> a very rare case.
>
> You see, here's the funny thing: It's rare because it's a hassle!
> *MY* experience (I do have some 20 years' worth of such...) is that
> people tend to use associative arrays instead for data records and the
> like. COPA aims to change that.


COPA won't make me use objects instead of arrays (in legacy code). The
problem is writing a ton of classes for all array ever used, in a legacy
file structure that comes with more maintenance than you'd like. What would
make me use objects would probably be run-time interfaces via a return
contract in combination with anonymous classes.


> > Most objects want and need to have private or protected properties for a
> large variety of reasons, which would make COPA useless.
>
> Ooops, careful with such an overstatement, buddy! I don't want to
> enter into this debate here, just point out that this generalisation
> is overreaching.
>

I don't remember when the last time was that I used public properties, even
for the simplest data objects. Constructors provide all the features I need
at this point, and I'm much more interested in making constructors have
less boilerplate than their initialization. I can imagine COPA being more
attractive once (public) read only properties are a thing, though even then
I'd much rather use a constructor as it will let me find usages and
add/swap arguments easily. Finding COPA usages of a class will be a lot
harder compared to constructors.

Regards,
Lynn

Re: [PHP-DEV] [RFC] Allow trailing comma in parameter lists

[Lynn]

On Thu, Mar 26, 2020 at 7:52 PM Nikita Popov  wrote:

> Hi internals,
>
> This has been declined in the past, but I just keep making this mistake,
> and believe it deserves reconsideration...
>
> https://wiki.php.net/rfc/trailing_comma_in_parameter_list
>
> Nikita
>

This would be a great addition, my "duplicate line" thanks you! (and so I)

Regards,
Lynn