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

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

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

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

Re: [PHP-DEV] PDO subclass names

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, &

Re: [PHP-DEV] PDO subclass names

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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 >

Re: [PHP-DEV] Custom object equality

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

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

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

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

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

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

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

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

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

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

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

Re: [PHP-DEV] PHP Package for PHP

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

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

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

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

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

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

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

Re: [PHP-DEV] Introduction - SuitespaceRnD

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

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

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

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

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

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

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

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

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?

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 >

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

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

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

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

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

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

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

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

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

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.

Re: [PHP-DEV] PHP 7.4.32 Released!

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

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

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

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

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)" >

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

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)

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

ing 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

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

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

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!

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

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

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

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

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 >

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

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

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

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

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

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(); > } > --- > >

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

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

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

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

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

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

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

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? &

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

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

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

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] ??

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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`

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

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()`,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [PHP-DEV] Type casting syntax

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

Re: [PHP-DEV] Type casting syntax

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

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

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

Re: [PHP-DEV] Proposal: clamp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

y 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

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

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.

. 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

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

e 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

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

lling a gap that's currently missing something. Regards, Lynn

Re: [PHP-DEV] Typed callable properties

for others. I'd imagine people will have missed this message. Regards, Lynn

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

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

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast

ts run periodically. I fully understand that you don't see this as a big issue, and I really wish I could say the same. I can't vote, so I can't change the outcome, please consider my use-case when moving forward, thanks! Regards, Lynn

Re: [PHP-DEV] [RFC] [DISCUSSION] Locale-independent float to string cast

On Tue, Mar 24, 2020 at 7:41 PM G. P. B. wrote: > On Tue, 24 Mar 2020 at 11:03, Lynn wrote: > >> I would like >> to see a warning of sorts so I can fix this before untested legacy code >> will seriously break data exports. >> >> Regards, >> Lyn

  1   2   >