Re: [PHP-DEV] [Pre-RFC Discussion] User Defined Operator Overloads (again)

On Sat, Sep 14, 2024 at 11:51 PM Jordan LeDoux wrote: > Hello internals, > > This discussion will use my previous RFC as the starting point for > conversation: https://wiki.php.net/rfc/user_defined_operator_overloads > > There has been discussion on list recently about revisiting the topic of > o

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

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

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 unilaterally

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 ma

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 tha

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 $which){`

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] [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 file

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 consensus

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

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 pro

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 strict_types

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 e

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 reje

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

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 fals

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 al

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( > #[PDOField

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 addr

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] 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) how/wh

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 an

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 functi

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 t

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] 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: > > https://wiki.php.net/rfc/namespaces_in_bundle

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] [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 would

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 cle

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

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

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

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

Re: [PHP-DEV] RFC proposal : "new" keyword shorthand

On Fri, Jun 7, 2024 at 11:50 PM Larry Garfield wrote: > On Fri, Jun 7, 2024, at 9:34 PM, Erick de Azevedo Lima wrote: > > Hi all. > > > >> Em sex., 7 de jun. de 2024 às 17:53, Pierre > escreveu: > >> I do agree with you that when you use value objects, you need it a lot, > >> but I'd much prefer

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

On Tue, Jun 11, 2024 at 3:15 AM Lanre wrote: > Why invest time in crafting yet another pull request or RFC when it's > glaringly obvious that you guys have no clue what you're doing? First, > there's the questionable decision to implement JIT in 8.0, followed by the > introduction of an entirely

Re: [PHP-DEV] [RFC] Static Constructor

On Wed, Jun 19, 2024 at 11:57 PM Mike Schinkel wrote: > On Jun 19, 2024, at 2:36 PM, Ilija Tovilo wrote: > On Wed, Jun 19, 2024 at 2:34 PM Erick de Azevedo Lima > wrote: > > New expressions continue to not be supported in (static and non-static) > property initializers and class constant initia

Re: [PHP-DEV] [Early Feedback] Pattern matching

On Thu, Jun 20, 2024 at 7:41 PM Larry Garfield wrote: > Hello, peoples. > > Ilija and I have been working on and off on an RFC for pattern matching > since the early work on Enumerations. A number of people have noticed and > said they're looking forward to it. > > It's definitely not going to m

Re: [PHP-DEV] [Early Feedback] Pattern matching

On Tue, Jun 25, 2024 at 9:44 AM Robert Landers wrote: > On Tue, Jun 25, 2024 at 2:48 AM Larry Garfield > wrote: > > > > On Thu, Jun 20, 2024, at 5:38 PM, Larry Garfield wrote: > > > > > To that end, we're looking for *very high level* feedback on this RFC: > > > > > > https://wiki.php.net/rfc/pa

Re: [PHP-DEV] [RFC] Static class

On Fri, Jun 28, 2024 at 2:48 AM Mike Schinkel wrote: > >> and inheritance is not meant for code reuse. > > Just because code reuse in inheritance can be problematic it does not have > to be in all-cases. Moderation in all things. I used that approach for 10+ > years and never once had any of the

Re: [PHP-DEV] [RFC] Static class

On Fri, Jun 28, 2024 at 8:04 PM Stephen Reay wrote: > > > On 28 Jun 2024, at 14:05, Lynn wrote: > > > > On Fri, Jun 28, 2024 at 2:48 AM Mike Schinkel wrote: > >> >> and inheritance is not meant for code reuse. >> >> Just because code reuse in in

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

On Fri, Jun 28, 2024 at 10:08 PM Máté Kocsis wrote: > Hi Everyone, > > I've been working on a new RFC for a while now, and time has come to > present it to a wider audience. > > Last year, I learnt that PHP doesn't have built-in support for parsing > URLs according to any well established standar

Re: [PHP-DEV] [RFC] Property Hook improvements

On Mon, Jul 1, 2024 at 7:05 PM Larry Garfield wrote: > Hi folks. As Ilija's been polishing off hooks to get the PR merged, we've > run into two small revisions that should make life better for all > involved. One is a performance improvement that requires a very slight > error handling behavior

[PHP-DEV] PHP header files, restrict to declaring code only

Hello everyone! This is my first mail to the internals, my apologies if I made a mistake somewhere. I would like to propose a new type of php "file" called "phph", short for "php-header". This file could receive an optional open-tag: `

Re: [PHP-DEV] PHP header files, restrict to declaring code only

s a header file as it might introduce more complexity than it's worth. Regards, Lynn van der Berg On Fri, May 10, 2019 at 2:37 PM Nikita Popov wrote: > On Fri, May 10, 2019 at 2:30 PM Lynn wrote: > >> Hello everyone! >> >> This is my first mail to the inte

Re: [PHP-DEV] PHP header files, restrict to declaring code only

On Fri, May 10, 2019 at 3:40 PM Dustin Wheeler wrote: > On Fri, May 10, 2019 at 9:15 AM Lynn wrote: > > > > 2. Certain features, can be restricted to php-header files only, meaning > it > > does not affect > >"normal" PHP files. This m

Re: [PHP-DEV] PHP header files, restrict to declaring code only

s for the developer consuming that public API. This is why I initially tried to come up with a strategy that allows you to define it in the file (one way or another). Note that my example with composer is tailored around my specific use-case and that a new function, keyword or statement might be more s

Re: [PHP-DEV] Re: [RFC] Namespace-scoped declares, again

concept of a package within PHP, rather than deducting it based off a namespace? If packages would be a thing in PHP, other than just a namespace, package private could also be implemented as visibility modifier for inheritance and class visibility. Regards, Lynn van der Berg

Re: [PHP-DEV] Improve visibility of RFC negative feedback

an index. This makes it very clear to see who provides which arguments. Regards, Lynn van der Berg

Re: [PHP-DEV] Improve visibility of RFC negative feedback

gle author, a link could be provided to a page where multiple authors post their summary. This could of course also be a page linking to other dedicated pages with one author per page. Regards, Lynn van der Berg

Re: [PHP-DEV] Bringing Peace to the Galaxy

quot;big" BC breaking changes would be added to the fancy version? Would we be looking at the removal of `==` comparisons in this fancy mode for example? Regards, Lynn van der Berg

Re: [PHP-DEV] RFC: var_export - short syntax for array

x27;t see this as an issue that PHP should solve. Regards, Lynn van der Berg

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

t can be solved by defining the variable with null value, but it's hard to trace without logging as we can't always set it with null value. Regards, Lynn van der Berg On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov wrote: > Hi internals, > > I think it's time to take a loo

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

This argument makes sense for arrays and objects (and I don't promote > undefined index/property to exceptions for that reason), but I don't think > it holds any water for simple variables. Writing @$counts[$key]++ is a lazy > way to count values and avoid ugly boilerplate for if > (isset($counts[$

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

> It would be great to have a package that reports all these cases, though we could try to craft something ourselves if this RFC is approved. Perhaps frameworks providing error handlers can add specific logging for these scenarios as well, saves you from putting more effort in this than required. Regards, Lynn van der Berg

Re: [PHP-DEV] Silent Types

lt value is given, such as with C# and type inference when declaring a variable, based on its assigned value. Regards, Lynn van der Berg On Wed, Sep 4, 2019 at 8:12 AM Michał Brzuchalski < michal.brzuchal...@gmail.com> wrote: > śr., 4 wrz 2019, 05:52 użytkownik Fwentish Aelondes >

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

is required to block certain access to users from certain countries. Regards, Lynn van der Berg

Re: [PHP-DEV] [RFC] Object Initializer

]) { $people[] = { Uuid id => $id, string username => $username, string name => $name, }; // and possible automatic assignment: $people[] = {Uuid $id, string $username, string $name}; } ``` Regards, Lynn van der Berg

Re: [PHP-DEV] Changing fundamental language behaviors

case? Most certainly, would've saved us a lot of headache, and money. You argue that it's a fundamental language change, I -and seemingly a lot of others- argue that this is more of a bug fix. Regards, Lynn van der Berg

Re: [PHP-DEV] Changing fundamental language behaviors

ant to consider the impact of a change, including for the Wordpress community. However, I think most people agree that the quality of Wordpress code and Plugins is highly debatable. I don't like the idea of not being able to progress because Wordpress users won't upgrade PHP. Regards, Lynn van der Berg

Re: [PHP-DEV] Changing fundamental language behaviors

rs. It wouldn't surprise me if a big portion of these applications could've also be a system written in another language, deployed, plugins installed, added some themes and done, no PHP knowledge required. Regards, Lynn van der Berg

Re: [PHP-DEV] [RFC] Object Initializer

s such, I > don't think it's a good idea to allow `new stdClass` to be omitted. > If the compiler implementation of `$foo = {...};` would give issues, `$foo = new {...};` could be an alternative for run-time declared anonymous classes (preferably with typed properties). In regards of stdClass, I don't think this should be used. Regards, Lynn van der Berg

Re: [PHP-DEV] [RFC] Union Types v2

here could also a type called `true`. Figured I'd toss in here as an out-of-the-box idea. Regards, Lynn van der Berg

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

erience, especially for new developers. For me this outweighs the BC break it will cause in the future, especially given it will be deprecated in 8.0 and thus gives developers an eternity to fix it. Regards, Lynn van der Berg

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

ld. I also don't see how school knowledge is important here, especially as I went to school and I did not learn about it there. Besides of this, there are also keyboard( layout)s that don't have a backtick character present. Regards, Lynn van der Berg

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

ot;. > > > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php Hi, I think it's best to discuss this in a new thread. This way the RFC thread can stay about this RFC. Regards, Lynn van der Berg

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

en go into a vote. If there are enough reasons to not deprecate them, the voting process will show this and the RFC will be rejected. Regards, Lynn van der Berg PS. We need a CoC.

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

objective way to incorporate userland concerns except when > some act as their proxy. Which is not the same as userland having explicit > representatives with a vote. > > I agree. There are a lot of unhappy user-land voices about a lot of decisions made here. Sadly I don't see a way to give everyone a voice in this. Regards, Lynn van der Berg

Re: [PHP-DEV] [VOTE] declare(function_and_const_lookup='global')

whether or not the function was defined via a `use` statement on top. I don't think your example of the diff would have a difference between `use` and `declare` when it comes to reviewing. I would advice developers to avoid using core function names in namespaces for custom functions, as doing this would open up a whole different can of worms when it comes to developer experience. Regards, Lynn

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

ferent result from what the new result will be? If I'd use a locale that results in `3.5`, I don't need a warning. If I use a locale that results in `3,5`, I would like to see a warning of sorts so I can fix this before untested legacy code will seriously break data exports. 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, >> Lynn &

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

k, or upgrade & work in the proposed scenario. Some breakage may take weeks to find out because scripts 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] 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] Compact Object Property Assignment

erties 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] Typed callable properties

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

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

holes, it's filling a gap that's currently missing something. Regards, Lynn

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

rgument) {} // 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] Shorter attribute syntax

p7 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] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

+ 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] About the use of the terms master/slave and blacklist, proposal to replace.

e 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] About the use of the terms master/slave and blacklist, proposal to replace.

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] [RFC][Discussion] Change terminology to ExcludeList

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] 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] 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] [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 matters

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 iterable_all

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 Tommi

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 li

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 exper

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 Joe

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 a

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 functio

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

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 would

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 will

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 >

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 poss

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 and/or

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 fixe

  1   2   >