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

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

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

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

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

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

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

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

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

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

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

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"

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

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

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:

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

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

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

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

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

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

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

[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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 al

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

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

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

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 need airbags &g

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

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

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

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

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

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

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

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

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

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

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

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

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 po

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

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

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

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

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

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

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

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

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

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

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

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

Re: [PHP-DEV] [RFC] [Draft] Final constants

Am 21.04.2021 um 17:08 schrieb Andreas Leathley : > On 21.04.21 15:14, Christian Schneider wrote: >> I never really understood the desire to restrict how people can use >> your code. >> If there is no good reason to override the value of a class constant people >> won

Re: [PHP-DEV] [RFC] [Draft] Final constants

Am 21.04.2021 um 14:25 schrieb Máté Kocsis : >> My point is actually what’s your scenario for a final constant? If you >> want to make sure the value you access are not changed by child class, >> `self::` can serve the purpose already. If you want to make sure > > > Yes, my intention is to

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

Am 25.03.2021 um 17:25 schrieb Larry Garfield : > So in conclusion, it seems the reasons closures weren't auto-capture always > were: > > 1) Possible performance concerns that are no longer relevant. > 2) Avoid surprise references. > 3) Allow users to capture by value or by reference. > > Point

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

Am 25.03.2021 um 14:29 schrieb Mark Randall : > On 25/03/2021 09:28, Rowan Tommins wrote: >> That's not quite what I meant. I meant that you can't say "capture by >> default, but this variable is definitely local". > > I think if there's one argument against, this would be it, but IMHO it is a

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

Am 24.03.2021 um 18:15 schrieb Chase Peeler : > I guess my one question would be why we didn't support auto-capture when we > first implemented anonymous functions, and if there was a reason, why does > that no longer apply? My guess would be that it was seen as one of PHP's big strength that

Re: [PHP-DEV] [RFC] Autoloader Classmap

Am 17.03.2021 um 02:51 schrieb Mark Randall : > It will be left to the voters to decide if 5% of an extremely common > operation is worth the few dozen lines of code required. Just to avoid misunderstanding things: This is a 5% boost of just the autoloading time, right? What does this

Re: [PHP-DEV] [RFC] Autoloader Classmap

Am 15.03.2021 um 18:41 schrieb Mark Randall : > I would like to propose the addition of a new mechanism of autoloading > classes - a classmap that will be consulted prior to checking the > spl_autoload_register'd callbacks. > > https://wiki.php.net/rfc/autoload_classmap Just so I understand

Re: [PHP-DEV] [PHP-DEV] [VOTE] Fibers

Am 11.03.2021 um 17:51 schrieb Chase Peeler : > If someone is willing to do the work to > add this to core, we aren't trading off other features in order to add it, > and it doesn't cause BC breaks or other bugs, what is the reason to not add > it? Complexity, which might come back and bite us

Re: [PHP-DEV] Small annoyances of PHP: Simple fixes would make tests fail

Am 19.02.2021 um 16:21 schrieb Sara Golemon : > On Fri, Feb 19, 2021 at 8:04 AM Christian Schneider <mailto:cschn...@cschneid.com>> wrote: > Indentation in var_export: > > The indentation for > var_export((object)[(object)[]]); > is off b

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

Am 04.03.2021 um 01:37 schrieb Ben Ramsey : > On Mar 3, 2021, at 14:25, Kamil Tekiela wrote: >> >> when both are strings then chances are that this is an error. > > Except when comparing two values from sources known to provide numbers as > strings, such as form input and database results. :-)

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

Am 03.03.2021 um 21:25 schrieb Kamil Tekiela : > Sorry Nikita, but adding special handling for edge-cases is only going to > make things messier. I didn't want to say that, as there is plenty of code out there who might fall in this trap this intermediate measure might still make sense. The

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

Am 03.03.2021 um 19:21 schrieb Stanislav Malyshev : > Nobody who applies == to strings and expects it to work out as stri g > comparison is doing the right thing. If you apply == to hex-encoded hashes, > that code is fubar, and fixing one particular corner case won't rescue it. So > I wonder if

Re: [PHP-DEV] Replies on lists.php.net

Am 15.02.2021 um 13:20 schrieb Pierre : > I noticed I receive almost all your replies to the list along with a > duplicated copy addressed to me or other conversation participants, I think > you always click "reply to all" instead of "reply to list" in your mail > client. I think if our

Re: [PHP-DEV] Small annoyances of PHP: Simple fixes would make tests fail

Am 19.02.2021 um 16:21 schrieb Sara Golemon : > On Fri, Feb 19, 2021 at 8:04 AM Christian Schneider <mailto:cschn...@cschneid.com>> wrote: > Stack traces: > == > > What version are you testing with. I know Niki killed some unnecessary frames > in 8.0's stackt

  1   2   3   4   5   6   >