Re: [PHP-DEV] Consensus on argument validation for built-in functions

Am 11.03.2025 um 16:29 schrieb Christian Schneider : > ...(if you want to be strict about warnings then just convert them to an > exception, that's easy enough)... Reading it back I maybe wasn't clear: I mean if you as an application developer want to be strict then you can use

Re: [PHP-DEV] Consensus on argument validation for built-in functions

Am 11.03.2025 um 12:54 schrieb Gina P. Banyard : > Taking the example of ext/pcntl again, if it were a standalone extension, > having it follow semver is a way more reasonable proposition. > Because we could just release 2 versions the same day, a x.y+1.0 introducing > a warning, and a x+1.0.0 wh

Re: [PHP-DEV] Consensus on argument validation for built-in functions

Am 11.03.2025 um 07:32 schrieb Gina P. Banyard : > On Monday, 10 March 2025 at 23:07, Jorg Sowa wrote: >> I’d like to align on the approach to validating arguments for built-in >> functions (usually for flag inputs). Some ongoing discussions in PRs: >> - https://github.com/php/php-src/pull/15647

Re: [PHP-DEV] RFC: Marking return values as important (#[\NoDiscard])

Am 29.01.2025 um 21:16 schrieb Rob Landers : > On Wed, Jan 29, 2025, at 20:50, Tim Düsterhus wrote: >> The `(void)` cast makes the intent of not being interested in the return >> value clear. In C casting to `(void)` is an established pattern of >> "using" a value that the compiler would otherwis

Re: [PHP-DEV] ext/sockets: socket_getpeername/socket_getsockname BC

Am 29.01.2025 um 04:20 schrieb David CARLIER : > Working on this PR #17440, I wanted to ask if the BC from these two calls > were ok because : > > Before > function socket_getsockname(Socket $socket, &$address, &$port = null): > bool {} > > After > function socket_getsockname(Socket

Re: [PHP-DEV] Inaccurate documentation on return values from native functions

Am 02.12.2024 um 13:31 schrieb Rowan Tommins [IMSoP] : > On 01/12/2024 23:50, mickmackusa wrote: >> I can appreciate that. Going forward, is there any benefit to preserving >> the behavior of returning integers beyond -1, 0, and 1? >> Should these topically related functions receive a new last ar

Re: [PHP-DEV] [Discussion] Make objects unpackable by default

Am 14.11.2024 um 22:27 schrieb Gina P. Banyard : > Agreed, this bites us constantly when needing to reason about what an > "object" is in PHP. > Similar to array it mixes the concept of a struct, with that of a reference > value, and "overloading" various behaviours (e.g. iterators and ArrayAcces

Re: [PHP-DEV] [Discussion] Make objects unpackable by default

Am 14.11.2024 um 10:59 schrieb Marco Pivetta : > On Thu, 14 Nov 2024, 11:29 MrMeshok, wrote: >> Hello, Internals! >> >> As you know if you try to unpack a regular object (`...$object`) you will >> get an error: Only arrays and Traversables can be unpacked. >> I don't really see a reason for this

Re: [PHP-DEV] [RFC] Change Directory class to behave like an opaque object

Am 14.09.2024 um 17:33 schrieb Gina P. Banyard : > I came across the Directory class while doing some code exploration of > ext/standard. > This class is effectively an opaque object for Directory resources, however > it doesn't behave like one, as it has existed since PHP 4. > > As such, I am p

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

Am 23.08.2024 um 12:27 schrieb Rob Landers : > On Fri, Aug 23, 2024, at 12:14, Christian Schneider wrote: >> Am 23.08.2024 um 11:34 schrieb Nick Lockheart : >> > I think we are all trying to achieve the same thing here. >> >> I'm not sure who "we" and

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

Am 23.08.2024 um 11:34 schrieb Nick Lockheart : > I think we are all trying to achieve the same thing here. I'm not sure who "we" and what "same thing" here exactly is. I recall the following arguments for changing the current situation about function look ups: - Performance - Function autoloadi

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

Am 21.08.2024 um 09:44 schrieb Faizan Akram Dar : > On Wed, Aug 21, 2024, 9:34 AM Christian Schneider > wrote: >> The point where I think we disagree is that it improves the code. It may >> improve performance of the code (even though I somewhat doubt this has a >> *sig

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

Am 20.08.2024 um 17:14 schrieb Levi Morrison : > Keep in mind that qualifying > every global function is annoying but probably can be somewhat > automated, and will bring better performance. So again, this improves > the existing code even without upgrading. Just to be sure: Would code *not* using

Re: [PHP-DEV] Time-out Posting to PHP Internals List

Am 16.08.2024 um 22:16 schrieb Kris Craig : > On Fri, Aug 16, 2024 at 8:11 AM Derick Rethans wrote: > >> You have therefore been given a 3-month timeout, which will be enforced >> by blocking you from sending email to the php.net domain, including >> subdomains. >> > This message kinda freaked

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

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

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

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

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

Am 09.03.2024 um 08:18 schrieb Marc : > As the pseudo type `mixed` exists since PHP 8.0, which is already > out-of-date, I have the feeling it would be better to force people to > explicitly write `mixed` to widen the type of an overwritten function and let > "no type" inherit the argument and r

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

Am 26.02.2024 um 14:25 schrieb Daniil Gentili : > I really don't think that a modern discussion system can afford to randomly > loose messages: mailing lists should not be used in 2024. Just because Gmail decided to tighten the rules about SPF/DKIM just now does not mean email is broken or loses

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

Am 26.02.2024 um 10:56 schrieb Daniil Gentili : >> gmail is failing to send emails to the list (hence why it has probably been >> a bit quite around here). Here is the error: > +1, personally I would just switch to github issues and discussions, even > ignoring all the deliverability issues, I do

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

Am 20.11.2023 um 22:00 schrieb Lanre Waju : > I will have to disagree with everything you said: Side-note: This is IMHO not a good intro into a discussion ;-) > I outlined what a static class would be: A class that cannot be instantiated > in which all members are implicitly static. We already h

Re: [PHP-DEV] Custom object equality

Am 18.10.2023 um 18:42 schrieb Larry Garfield : > So the real question is: Would anyone who voted No on operator overloading > before vote Yes on it if it used ~=, ~>, ~+, etc. instead? I confess that I'm not a fan of operator overloading for a language like PHP but introducing new operators on

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

Am 18.10.2023 um 10:42 schrieb Daniil Gentili : > This is precisely why I'm planning to submit the RFC to make the change in > PHP 8.4, which is when the new JIT will be introduced. Ah, I missed that part, my bad. I'd suggest mentioning this in the RFC. I also went back Dmitry's RFC and saw that

Re: [PHP-DEV] Deprecate posix_times

Am 17.10.2023 um 19:39 schrieb Daniil Gentili : > I would like to submit an RFC (and related PR) to deprecate posix_times for > PHP 8.4, removing it for PHP 9. My question here would be: Is there sufficient reason to remove this function and introduce a BC break, i.e. is the implementation code

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

Am 17.10.2023 um 19:46 schrieb Daniil Gentili : > I would like to submit an RFC and PR to change a few INI defaults for > opcache, changing how JIT is disabled by default. > > Currently, JIT is disabled by default using the |opcache.jit_buffer_size=0| > default, instead of |opcache.jit=0|. > >

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

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

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

Am 05.06.2023 um 19:59 schrieb Niels Dossche : > I'm opening the vote now on my proposal to include mb_str_pad() into PHP 8.3. > RFC link: https://wiki.php.net/rfc/mb_str_pad I voted "No" because I think it should be grapheme_str_pad instead and I'd like to avoid having both the mb_ and grapheme_

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

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

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

Am 30.03.2023 um 10:50 schrieb Lynn : > That said, mailing lists are ancient and in my opinion a horrible way of > doing things. Mailing lists have been around for a long time, yes, but it also means the way we use it for larger scale communication has been refined over time. Please consider th

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

Am 29.03.2023 um 11:55 schrieb Tim Düsterhus : > On 3/29/23 11:42, Sebastian Bergmann wrote: >> Am 29.03.2023 um 11:31 schrieb Rokas Šleinius: >>> I wouldn't say removing the final attribute from enums actually "breaks" >>> any functionality. >> I am with Marco on this: removing the "finality" fro

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

Am 28.03.2023 um 14:42 schrieb G. P. B. : > On Tue, 28 Mar 2023 at 08:19, Christian Schneider > wrote: >> There are two cases I would handle differently: >> - I'm not sure why a negative step for $start > $end is considered wrong, I >> consider range(10, 0, -2)

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

Am 28.03.2023 um 00:22 schrieb Larry Garfield : > On Mon, Mar 27, 2023, at 2:12 PM, Mel Dafert wrote: >> On 27 March 2023 20:20:58 CEST, "Michał Marcin Brzuchalski" >> wrote: >>> Personally, I'd like the unserialize to throw an exception if trailing >>> bytes are detected. >>> If not by default

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

Am 28.03.2023 um 00:36 schrieb G. P. B. : > I therefore propose the "Define proper semantics for range() function" RFC > to address the unintuitive behaviour that sees no usage and/or hide bugs: > https://wiki.php.net/rfc/proper-range-semantics > > The change propose to throw TypeErrors and ValueE

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

Am 10.03.2023 um 20:04 schrieb Eugene Sidelnyk : > Another simplified example: > > ``` > // partial application > foo(bar(1, ...)); While it is not as concise as your version I think the work-around with short arrow functions works ok unless your code is full of partial applications: foo

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

Am 01.03.2023 um 01:13 schrieb Bob Weinand : > In this case, while the primary concern of the RFC was rejected, I think it's > pretty clear, that there was a supermajority for something specific. I didn't vote on this RFC but I have to disagree with you and Max here: My understanding of such a v

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

Am 28.02.2023 um 22:04 schrieb Max Kellermann : > On 2023/02/28 21:16, Dmitry Stogov wrote: >> Recently we voted for inluce cleanup RFC >> https://wiki.php.net/rfc/include_cleanup and it was declined. > > Which specific commits do you wish to revert? Is this about include > cleanups (none of w

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

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

Re: [PHP-DEV] Measuring Proposal Reaction

> Am 18.01.2023 um 23:29 schrieb Larry Garfield : > On Tue, Jan 17, 2023, at 1:25 PM, Jesse G. Donat wrote: >> I'm looking to measure reaction to a proposal. >> >> My proposal is to have the STDOUT and STDERR global constants always >> defined rather than just when running via CLI. > > Does any

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

Am 18.01.2023 um 16:26 schrieb Claude Pache : >> Le 18 janv. 2023 à 16:20, Derick Rethans a écrit : >> >> if (version_compare(phpversion(), "8.4.0", ">")) { >> setcookie("test", "value", samesite: SameSite::Stricter); >> } else { >> setcookie("test", "value", samesite: SameSite::Strict); >> } >

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

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

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

Am 16.01.2023 um 14:39 schrieb G. P. B. : > On Sun, 15 Jan 2023 at 20:58, Christian Schneider > wrote: > Some comments: > - I am not convinced that we should introduce a third way of providing > parameters to setcookie(). I don't think this function is used often enough >

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

Am 14.01.2023 um 16:14 schrieb G. P. B. : > I would like to start the discussion about the Add SameSite cookie > attribute parameter RFC: > https://wiki.php.net/rfc/same-site-parameter > > This proposes to add an optional same site parameter to the setrawcooki(), > setcookie() and session_set_cook

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

Am 11.01.2023 um 17:09 schrieb Christoph M. Becker : > On 11.01.2023 at 15:19, Christian Schneider wrote: > >> Am 11.01.2023 um 15:04 schrieb Christoph M. Becker : >>> On 11.01.2023 at 14:07, Christian Schneider wrote: >>> >>>> While migrating to

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

Am 11.01.2023 um 15:04 schrieb Christoph M. Becker : > On 11.01.2023 at 14:07, Christian Schneider wrote: > >> While migrating to PHP 8.2 we noticed the change in strtotime. >> PHP <= 8.1 supported "today +- 3 days" etc. but the support for multiple >> sign

[PHP-DEV] Adding strtotime change to migration document

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

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

Am 24.10.2022 um 04:56 schrieb BohwaZ : > I am proposing that the SQLite3 extension stops using warnings for > errors and instead throws exceptions by default: > > https://wiki.php.net/rfc/sqlite3_exceptions > > Whether we just deprecate warnings first and default to exceptions, and > then remove

Re: [PHP-DEV] Experimental features

Am 11.10.2022 um 07:09 schrieb MKS Archive : >> On Oct 10, 2022, at 8:04 PM, David Gebler wrote: >> >> This is what's bothering me. Either these "experimental" features have >> passed RFC and will be part of the language, as you've said above, or >> they're actually experimental i.e. not finalize

Re: [PHP-DEV] Experimental features

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

Re: [PHP-DEV] Experimental features

Am 05.10.2022 um 15:38 schrieb Alex Wells : > Advantages of experimental features over extensions: > - they allow changes to the parser > - they are universally supported (by IDE's, parsers etc) because they are > part of a stable language release, not an unpopular/unknown extension > - usages of t

Re: [PHP-DEV] ksort breaking change

Am 26.08.2022 um 18:28 schrieb Sara Golemon : > What I can see is two noble, but conflicting ideals: > 1/ sort() and ksort() should be consistent about their sorting algorithms. > I think we can all agree about that in the ideal case, at least. > 2/ Behavior within a minor release should be self-co

Re: [PHP-DEV] ksort breaking change

Am 26.08.2022 um 14:19 schrieb Christoph M. Becker : > On 26.08.2022 at 05:15, Go Kudo wrote: > >> In the actively supported version of PHP, `ksort()` has been modified to >> include BC Break. >> >> https://github.com/php/php-src/issues/9296 >> >> This may seem like an appropriate bug fix, but i

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

Am 11.08.2022 um 11:03 schrieb Alex Wells : > That’s just a concept. I’d love to bring a lot more examples in an RFC if > there’s more positive than negative feedback. Again, I’m more looking for > feedback than trying to convince someone, but I’ll showcase a couple real > comparisons for some c

Re: [PHP-DEV] Stricter implicit boolean coercions

Am 26.04.2022 um 15:16 schrieb Andreas Leathley : > On 26.04.22 14:47, Christian Schneider wrote: >> There are two big reasons: >> - BC: Checking for the truthiness of a value is very common and would >> require a lot of code changes. >> - Some of us like the concisen

Re: [PHP-DEV] Stricter implicit boolean coercions

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

Re: [PHP-DEV] NULL Coercion Consistency

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

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

Am 24.03.2022 um 10:32 schrieb Rowan Tommins : > On 23/03/2022 23:39, Juliette Reinders Folmer wrote: >> >> While I agree the functions are often used incorrectly, what worries me >> about this RFC is that the only viable alternatives for these functions are >> in two optional extensions, which

Re: [PHP-DEV] Discussion: String streams

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

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

Am 16.03.2022 um 11:39 schrieb Mark Randall : > On 16/03/2022 09:17, Christian Schneider wrote: >> Maybe we should ask ourselves the question: Why would the entire package be >> blocked? Just because it is too big or maybe there *are* subtleties which >> have not b

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

Am 16.03.2022 um 10:00 schrieb Mark Randall : > On 15/03/2022 23:02, Patrick ALLAERT wrote: >> I am not against the fact this warning becomes an error per se. I am just >> not very fan of cherry-picking an individual kind of problem (read: >> notice/warning/error/...) and changing it without a more

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

Am 16.03.2022 um 06:52 schrieb Juliette Reinders Folmer : > I've just been looking in detail at the Partially Supported Callables > deprecation RFC: > https://wiki.php.net/rfc/deprecate_partially_supported_callables > > The RFC explicitly excludes the `is_callable()` function and the `callable`

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

Am 15.03.2022 um 20:07 schrieb Miguel Rosales : > Christoph M. Becker wrote on 15/3/22 19:17: >> That explicitly excludes undefined array indexes, and apparently also >> excludes undefined properties (which raise "Warning: Undefined property:") >> > AFAIU error promotion for undefined properties h

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

Am 03.03.2022 um 10:11 schrieb Kalle Sommer Nielsen : > Den tor. 3. mar. 2022 kl. 10.48 skrev Sergey Panteleev > : >> >> I'd suggest making a PR with the News (press release) in web-php >> and maybe discussing it already on GitHub, >> since it would get more coverage and we can hear more opinions

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

Am 01.03.2022 um 11:43 schrieb Christoph M. Becker : > On 28.02.2022 at 23:11, Christian Schneider wrote: > >> Am 28.02.2022 um 22:05 schrieb Christoph M. Becker : >> >>> On 28.02.2022 at 21:51, Craig Francis wrote: >>> >>>> And after all o

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

Am 28.02.2022 um 22:05 schrieb Christoph M. Becker : > On 28.02.2022 at 21:51, Craig Francis wrote: > >> And after all of this, no-one has come up with a way to find or address >> this problem, e.g. >> >> > $nullable = ($_GET['a'] ?? NULL); >> echo htmlentities($nullable); >> ?> > > function

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

Am 07.02.2022 um 13:07 schrieb G. P. B. : > On Mon, 7 Feb 2022 at 09:34, Christian Schneider <mailto:cschn...@cschneid.com>> wrote: > > If a parameter expects a string, that is what it should be given, and its > > the callers' responsibility to ensure that is the cas

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

Am 07.02.2022 um 09:35 schrieb Mark Randall : > On 07/02/2022 01:27, Craig Francis wrote: >> I know one person simply said this was a "terribl > idea", but I'm still >> waiting to hear any details on why. > > I understand your motivations in proposing them, but to my mind it goes > against the di

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

Am 30.01.2022 um 16:55 schrieb Nikita Popov : > Something I want to add here is that there is also an important technical > motivation behind promoting undefined variable notices to exceptions: The > big problem with these (from a pure implementation perspective) is that we > need to throw the warn

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

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

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

Am 28.01.2022 um 23:57 schrieb Jordan LeDoux : > > On Thu, Jan 27, 2022 at 12:24 AM Christian Schneider <mailto:cschn...@cschneid.com>> wrote: > > My issue with this is that while it seems to work towards the goal of "fail > fast" it does not completely fulf

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

Am 27.01.2022 um 23:41 schrieb Mark Randall : > What we don't want to do, I think, is end up in a situation like JS where it > has to be opted in: https://www.w3schools.com/js/js_strict.asp That's why the majority decided a while ago that you don't have to opt-in right now: The default error_rep

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

Am 27.01.2022 um 05:17 schrieb Mark Randall : > It is my firm believe that a language such as PHP should not be dependent on > static analysers to protect users against engine-level problems that may > occur during runtime. My issue with this is that while it seems to work towards the goal of "f

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

Am 26.01.2022 um 17:42 schrieb Craig Francis : > While I did begin an RFC to allow *some* functions to be more tolerant of > NULL, especially for those scripts not using `strict_types`: > > https://wiki.php.net/rfc/allow_null > > Or in other words, to "relax certain type requirements on a case by

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

Am 26.01.2022 um 16:55 schrieb Lynn : > I don't want to waste time trying to figure out if an undefined `$j++` is a > bug because it should've been `$i++`, or that `$i = 0;` is supposed to be > unused because someone forgot to remove it. Given the legacy I work with, > it's unrealistic to have s

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

Am 25.01.2022 um 00:47 schrieb Mark Randall : > ** Undefined Variables Promoted to Error ** > > PHP currently treats reading an undefined variable as though it were a null, > emitting a warning message in the process. This was previously promoted from > a notice in the PHP 8 engine warnings RFC.

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

Am 31.12.2021 um 03:21 schrieb Kirill Nesmeyanov : > I support this behavior fix because in its current form, due to a similar > problem (almost?), all PSR-7 implementations contain bugs that violate > RFC7230 (section 3.2: > https://datatracker.ietf.org/doc/html/rfc7230#section-3.2 ). Thus, >

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

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

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

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

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

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

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

Am 17.09.2021 um 04:09 schrieb tyson andre : > I've created a new RFC https://wiki.php.net/rfc/vector proposing to add > `final class Vector` to PHP. First of all: I don't have a strong opinion on a Vector class being useful or necessary. But I have two comments about this RFC: 1) Using the ve

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

Am 06.09.2021 um 18:08 schrieb Benjamin Morel : > Yes, please! A future where dynamic properties are only allowed on > DynamicObject is bright. I have nothing against a DynamicObject alias for people who like to be more explicit in their code... > I would even deprecate the stdClass alias straig

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

Am 06.09.2021 um 16:46 schrieb Pierre Joye : > Also as someone mentioned here afterwards, instead of removing it > straight away, I would go with the flag first, less risky :) Out of curiosity: Do you think disabling the stat cache could be harmful? If no, why make it an option? If yes, should we

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

Am 05.09.2021 um 13:30 schrieb Kevin Lyda : > Any more thoughts on https://github.com/php/php-src/pull/5894 ? > I've resolved the merge conflict. It would be nice to close out this bug. For the record in case it was missed: If we deem the stat cache to be useless I'd rather remove it completely to

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

Am 03.09.2021 um 18:12 schrieb Kevin Lyda mailto:ke...@lyda.ie>>: > To run this php script: > > $iterations = 100; > function all_the_stats($filename) { > @lstat($filename); > @stat($filename); > } > while ($iterations--) { > all_the_stats(__FILE__); > } > > I see this output: > > Wit

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

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

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

Am 03.09.2021 um 16:07 schrieb Kevin Lyda : > On Fri, Sep 3, 2021 at 2:34 PM Christian Schneider > wrote: >> If I remember correctly it was about reducing the number of system calls. Is >> this no issue any more? >> Has a quick benchmark been done to see the positive

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

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

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

Am 21.06.2021 um 18:54 schrieb tyson andre : > return [success: true, data: $data, cursor: $cursor]; > // is equivalent to the following, but shorter: > return ['success' => true, 'data' => $data, 'cursor' => $cursor]; Just a little side-note: A while ago I proposed a 2-line-patch to allow :$foo

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

Am 03.06.2021 um 22:47 schrieb Kamil Tekiela :I love this idea. We should definitely make it official that procedural > style API is unfavourable and should not be added to new classes. > On top of that, I would be in favor of deprecating all existing procedural > APIs. > - It's making it more dif

Re: [PHP-DEV] Disable autovivification on false

Am 25.05.2021 um 18:23 schrieb Kamil Tekiela : > I'd like to start a discussion on the following RFC > https://wiki.php.net/rfc/autovivification_false > Particularly, I am looking for opinions on whether this behaviour should be > left alone, should be disabled on false, or should be disabled on nu

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

Am 11.05.2021 um 23:20 schrieb Larry Garfield : > 3) Perhaps it should be named RandomSequence or similar? It's not truly > generating random numbers. It's generating a repeatable but difficult to > produce sequence off of a seed value. That's not the same thing as > random_int() et al. > >

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

Am 11.05.2021 um 19:02 schrieb Calvin Buckley : > - almost all modern mail clients are threaded, it's trivial to view > context, so I want to see replies "above the fold" Funnily enough the fact the mail clients are threaded nowadays is a good reason for me to use inline replies with rigorously t

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

Am 11.05.2021 um 18:42 schrieb Kamil Tekiela : > Compare the two messages from Sara, the first where she top posted and the > second where she bottom posted. Which one is more clear? > https://imgur.com/TUiHval The second one which shows me what Sara is referring to. Imagine it just said "I don't

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

Am 11.05.2021 um 17:01 schrieb Mel Dafert : >>> This plaintext reply sent via Gmail web client. I don't know what Mel is >>> talking about either. >>> >> Gmail's web client is what I normally use, and have never had an issue with >> it. > > Sorry for being unclear - I meant the Gmail android app.

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

No. Outlook is not modern. No. That's not the point, the missing context is. Sorry, could not resist ;-) - Chris > Am 10.05.2021 um 23:51 schrieb Kamil Tekiela : > > Hi Internals, > > Could we drop the bottom-posting rule? > > Almost all new contributors fall into this trap and reply to a th

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

Am 07.05.2021 um 03:44 schrieb Ben Ramsey : > On 4/28/21 06:17, G. P. B. wrote: >> On Wed, 28 Apr 2021 at 12:12, David Gebler wrote: >>> Hi internals, >>> I've opened a PR to cause compact() to throw a TypeError if its parameters >>> are not valid, which I consider to be a fix for what is effectiv

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

Am 29.04.2021 um 10:14 schrieb Rowan Tommins : > On 28/04/2021 23:00, Nuno Maduro wrote: > 3) All variables are captured, there is no local scope. This is effectively > what PHP's single-expression closures use. > > Option 3 is the easy option, and is currently "good enough" because it's rare >

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

Am 28.04.2021 um 01:00 schrieb Larry Garfield : > However! Classic OOP design patterns are not all that PHP supports, and > that's a good thing. The "class" construct, for better or worse, is the > syntax for logic objects, value objects, data objects, and control flow > objects (such as Maybe

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

Am 27.04.2021 um 19:19 schrieb Pierre : > I think that the debate "but if your seal your classes I won't be to extend > it" is overrated: it's not the language to chose whether or not the > library/software author can seal its classes or not, it's up the > library/software author to do its own c

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

Am 26.04.2021 um 14:18 schrieb Ilija Tovilo : > The point of sealed type is to fix the number of subclasses a given > type can have, which means you can handle a value by type (as that > list is not finite). Code that handles Optional values could look like > this: > > ``` > if ($option instanceof

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

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

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

Am 24.04.2021 um 21:51 schrieb Marco Pivetta : > On Sat, Apr 24, 2021, 21:44 Olle Härstedt > wrote: > >> 2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati : Doesn't this violate the principle: It should be possible to add new features without touching old code?

  1   2   3   4   5   6   7   >