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

eloper 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 suitable for develope

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 internals

[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

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] [RFC] Reclassifying engine warnings

efining 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 look at our existing warnings & notices

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

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

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

issue that PHP should solve. Regards, Lynn van der Berg

Re: [PHP-DEV] Silent Types

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 > napisał: > > > Hello internals, > > > &g

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

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

'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

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

t 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] Union Types v2 (followup on github usage)

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

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

cept 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

ltiple 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] Improve visibility of RFC negative feedback

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

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

king 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] Union Types v2

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

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

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

o 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] [RFC] Deprecate Backtick Operator (V2)

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

wledge 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] [VOTE] declare(function_and_const_lookup='global')

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

for others. I'd imagine people will have missed this message. 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

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] [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] Mixed type

lling a gap that's currently missing something. 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] [DISCUSSION] Locale-independent float to string cast

rom 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 On Tue, Mar 24, 2020 at

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

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

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

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

  1   2   >