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

Hi! That is something PHP is missing atm, no one can verify the build process for releases. Yes that's what I was suggesting. This should be done by RM. In that way, the RM becomes more someone that verifies the build and not the actual person that provides the build. I'm not

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

Hi! On 3/30/24 1:27 AM, Sebastian Bergmann wrote: Am 30.03.2024 um 05:17 schrieb Ben Ramsey: This is also why our release managers sign the tarballs with their own GPG keys, after generating the artifacts. This verifies the release manager was the one who generated the files. But does the

Re: [PHP-DEV] [RFC] [VOTE] Change the edge case of round()

Hi! I've voted no, but only because I think that because this is technically a documented (through RFC) BC break, it should wait for PHP 9, and not for any 8.*. I think so too, it's a frequently used function, and while the argument for the change look convincing, changing it an advanced

Re: [PHP-DEV] Security Audit Priorities

Hi! This reminds me of something. There's an interesting paper about ReDoS resilience in different regex engines. Some programming languages, including PHP, are evaluated there and compared: https://www.usenix.org/system/files/sec22-turonova.pdf PHP has some configuration knobs for pcre

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

Hi! I think what could be proposed instead is to enable GitHub discussions for discussing ideas before they are proposed on the mailing list. It could be Don't see any problem with that if somebody would be willing to keep an eye on it and do the moderator duties (unfortunately, any public

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

Hi!  I'm not sure why it's assumed that participating in discussions is the same as actually developing PHP. I'm sure there are plenty of folks Right. And participating meaningfully requires some level of commitment and investment. For example, willingness to familiarize oneself with some

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

Hi! - having to subscribe to a mailing list to even see the discussions Not really, there are archives. - having to learn the specific, uncommon rules of replying: bottom If learning a couple of very simple rules is too much for you, maybe you are too busy to take on yourself another

Re: [PHP-DEV] LDFLAGS broken?

Hi! There seems to be another unset done to this change here: https://github.com/php/php-src/commit/c4d84aa33390045cd4ff542719a0f79cff52fb7c which fixed some bugs related to linker errors and duplicate symbols. Smells like people doing random things until some bug disappears... and no commit

[PHP-DEV] garbage in bugs.php.net

Hi! Somebody have put a ton of garbage reports in bugs.php.net under security bugs. Cleaning them up manually is kind of annoying, could somebody with DB access go in and clean them all up? They all have either OS or Summary field set to "1" as far as I can see. Thanks, -- Stas Malyshev

Re: [PHP-DEV] Re: [RFC] Migrating to GitHub issues

Hi! I had enabled that some weeks ago, since there has been a spam attack on bugsnet, so we could test the new feature. I probably should have written to list right away, or at least have kept an eye on it, but I've assumed to be notified about reported issues. I'll have a closer look at the

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

Hello all, I do not know if anybody here knows much about me personally, but I was born in Ukraine, lived there for all my youth and my relatives and friends are still there. You can imagine my feelings about this horrible attack on Ukraine that is going on right now. I am sincerely and

Re: [PHP-DEV] RFC proposal to deprecate crypt()

Hi! The RFC is about deprecation, not removal. If it's not going to be removed, what's the point of annoying people with deprecation warnings (that they would patch out/silence anyway)? If we want to document which functions are recommended to be used in which case, we have the manual for

Re: [PHP-DEV] RFC proposal to deprecate crypt()

Hi! On 2/19/22 6:03 PM, st...@tobtu.com wrote: crypt() should be deprecate because it can be used to create bad password hashes: I don't think it's a good reason for deprecating functions. A lot of functions, if used incorrectly, could produce bad results, it's not the reason to not use

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

Hi! I don't think this behavior should be considered as "normal" and would like to propose to change this for PHP 9, as it's a BC-break. To me it can and It'd not be just a BC break, it'd be an absolutely massive BC break that has a potential to break a ton of code and would be extremely

Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)

Hi! On 12/17/21 9:43 AM, Matt Fonda wrote: Hi Jordan, Thanks for the RFC. I have a couple questions: Suppose I have classes Foo and Bar, and I want to support the following operations: - Foo * Bar (returns Foo) - Bar * Foo (returns Foo) If I understand correctly, there are three possible

Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)

Hi! 3. I am already aware of several people within internals that believe any version of this feature will result in uncontrolled chaos in PHP codebases. I think this is false, as I do not see that kind of uncontrolled chaos in the languages which do have this feature. However I would think

Re: [PHP-DEV] Re: [RFC] Migrating to GitHub issues

Hi! > With Laminas, we use an email alias to allow researchers to report to us. > We then post the full report as a security issue on GitHub - it's a feature > they rolled out late 2019/early 2020 that restricts visibility to > maintainers initially, but allows inviting others to collaborate

Re: [PHP-DEV] Unbreak git.php.net links?

Hi! On 10/3/21 9:48 PM, Joe Watkins wrote: I just realised you're probably talking mostly about links in old comments on bugs rather than in source code of bugsnet (because they would be easy to find). Maybe permanent redirects aren't so bad in that case. But also, can't we just update the

[PHP-DEV] Unbreak git.php.net links?

Hi! I know we're no longer using git.php.net, but there are a lot of links there e.g. in bugs system. I wonder how hard it would be to make git.php.net redirect links like this: http://git.php.net/?p=php-src.git;a=commit;h=3c939e3f69955d087e0bb671868f7267dfb2a502 to something like:

[PHP-DEV] Spam on bugs.php.net

Hi! I notice that we have increased amount of spam coming in to bugs.php.net. I'm not sure if anyone is maintaining it right now - but it'd be nice to have changes to counter that - I see that anti-spam measures exist on some forms but not on adding comments to closed bugs for some reason.

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

Hi! The crux of the issue is what our end goal is: 1. Require users to explicitly annotate classes that use dynamic properties, but otherwise keep dynamic properties as a fully supported part of the core language. 2. Remove support for dynamic properties entirely. The core language only has

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

Hi! I think PHP’s biggest strength is its large and active community. But in my opinion, PHP (source/internals) often miss to benefit from our great community. I am happy to help making changes, but I feel like it is an impossible task for me… I mean, I cannot even update an outdated wiki

Re: [PHP-DEV] Re: open_basedir?

Hi! Apparently, there has been no resolution for this issue so far. While I don't really care about the open_basdedir directive per se, I fully agree that we should not advertize it as security feature, and to clearly state this in the PHP manual, as well as in our security policy. Correct.

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

Hi! No I don't agree.  People can do whatever is convenient for them.  Some will top-post; Some will bottom-post and some will inter-post.  By interpost I mean people will try to respond to a post on a point by point basis. The thing is when you alone, you're free to do what is convenient

Re: [PHP-DEV] Re: Bugsnet

Hi! It might just be an illusion, but it feels like all three projects have a lot more resources to spend on all this than PHP does; Rust has "Working Groups", Kubernetes has "Special Interest Groups", and PHP struggles to assign each module a single maintainer. How that affects our tooling

[PHP-DEV] Re: Bugsnet

Hi! If at some time in the future, github becomes a less than suitable environment for us, we can just move, no problem. There's no sense in which we are locked into anything. I don't see how we could "just move" if all our bug handling would be wired into Github. I can easily see how we

[PHP-DEV] Re: Bugsnet

Hi! Quite aside from spam problems, bugsnet is hidden away in a dark corner of the internet that requires a special login, doesn't integrate with source code or our current workflow (very nicely), and doesn't get updated or developed. Having moved our workflow to github, now seems to be the

Re: [PHP-DEV] PHP Language Specification

Hi! I wonder what to do with the PHP Language Specification[1]. Apparently, the repo is abandoned (last commit was more than a year ago, although PHP 8 changed quite some stuff). If we don't have the bandwidth to maintain it, we should mark it as unmaintained, and maybe some of the

[PHP-DEV] Re: [PHP-CVS] [php-src] master: Fix build warning

Hi! On 4/27/21 1:11 AM, Nikita Popov wrote: Author: Nikita Popov (nikic) Date: 2021-04-27T10:10:22+02:00 Commit: https://github.com/php/php-src/commit/310c0561a9e5ec9a0414654cc96fb2b3c7e1abc7 Raw diff: https://github.com/php/php-src/commit/310c0561a9e5ec9a0414654cc96fb2b3c7e1abc7.diff Fix

Re: [PHP-DEV] wiki.php.net upgrade

Hi! Nobody has updated the wiki in several years, despite warnings, and two very public breaches of security that we know about. I think it's just because nobody has focused attention to it. As you see, once it was focused, it has happened. Thanks, -- Stas Malyshev smalys...@gmail.com --

Re: [PHP-DEV] wiki.php.net upgrade

On 4/8/21 7:44 AM, Niklas Keller wrote: Hey all, the wiki is up to date now with the help of @Sergey Panteleev . :-) Thank you both! -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] wiki.php.net upgrade

Hi! If we want to keep using wiki.php.net then, sure, we should update it. We could also migrate the wiki to GitHub. We also already have https://github.com/php/php-rfcs which we could use for RFCs instead of a wiki going forward. Wiki isn't used only for RFCs, there's more content there

[PHP-DEV] wiki.php.net upgrade

Hi! Given that we're upgrading and updating our infrastructure, maybe it's time to update the wiki.php.net wiki too? I count five upgrade warnings there now, and I am not sure, but I think we could assume there were some bugfixes in it since 2017. -- Stas Malyshev smalys...@gmail.com -- PHP

Re: [PHP-DEV] Raising the precedence of the new operator

Hi! On 4/5/21 9:40 AM, André Hänsel wrote: I was wondering... PHP is the only language I know of where you have to write `(new Foo())->bar()` instead of `new Foo()->bar()`. This is particularly apparent with the builder pattern: Enabling something that is syntax error now sounds pretty

Re: [PHP-DEV] Changes to Git commit workflow

Hi! On 3/29/21 4:49 AM, Max Semenik wrote: On Mon, Mar 29, 2021 at 1:53 AM Nikita Popov wrote: changes should be pushed directly to GitHub rather than to git.php.net. Would it also make sense if direct pushes (bypassing the pull requests system) were disallowed completely? I can see

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

Hi! > date_sunrise() and date_sunset() Do we have any information on usage? I am generally not a fan of deprecating functions that work - even if they are odd and have quirky APIs - but if the usage is essentially zero than it might be ok. > key(), current(), next(), prev(), and reset() on

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

Hi! PHP's == comparison semantics for strings have a peculiar edge-case, where comparisons of the form "0e123" == "0e456" return true, because they are interpreted as floating point zero numbers. This is problematic, because strings of that form are usually not numbers, but hex-encoded hashes

Re: [PHP-DEV] Travis CI migration?

Hi! Any news here? Tomorrow PHP 7.3.27 will be tagged, likely without any Travis-CI build to confirm that it's not broken on Linux. As far as I can see, it's migrated to .com, but we're currently out of free credits. Not sure how we run through them so fast, we may need to adjust the cron

Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

Hi! He's also apparently has been emailing people individually off-list according to: https://news-web.php.net/php.internals/112833 If anyone else receives unpleasant emails from him (or from anyone else), please either: * forward them to the list for all to see. * forward them to myself, if

Re: [PHP-DEV] Travis CI migration?

Hi! The exception being the PHP-7.3 branch, which in security mode. Unless we add GH CI for that branch as well, switching to travis-ci.com seems to be useful. Maybe we get enough free credits for the relatively rare builds? I don't think it's possible to migrate only one branch, but if we

[PHP-DEV] Travis CI migration?

Hi! Today I noticed the message on travis-ci.org: Please be aware travis-ci.org will be shutting down in several weeks, with all accounts migrating to travis-ci.com. Please stay tuned here for more information. As far as I know, our repo is still not migrated. Anybody looked into it? Also,

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

Hi! While it's clear that passing e.g. an array falls into the scope of that general note, it doesn't say anywhere on that page that a string value which contains "\0" is "not what it expects", and I don't think I would ever have guessed that before reading this thread. So I stand by my

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

Hi! Just to reiterate, the previous implementation was also bad - it returned an entirely undocumented and unexpected null value. PHP functions always returned null on bad parameters, so it's not exactly unexpected. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Strict switch

Hi! I'm referring to support for non-trivial expressions, aka blocks. Say, the ability to split up a long expression by using a meaningful temporary variable. Block support is sufficient to cover *most* switch use-cases, obviating the need to introduce a new switch variant. We could take a

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

Hi! yeah, you should think about external input *before* do anything with it, always! if you pass a random path with NULL you did not do anything to validate the input Yes, and? is_file should be safe (as in, not exploding and breaking the whole app) on any input (leaving typing discussion

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

Hi! we are running error_reporting E_ALL for 17 years now and don't distinct between notice / warning / error, it has to be fixed - period Surely you do. Your code continues to run after warning/notice but stops after the error. It's impossible to ignore that. Unless you have an error handler

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

Hi! First, assuming that a null byte in a file name *is* an error condition, is the PHP 8 behavior better than in PHP 7? I think the answer to this one is very clearly "yes". The above code snippet and the subtle way in which it For me as a user that would be a very clear "no". Now if I have

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

Hi! So why having is_file()/is_dir() throw a warning for the past 8 years (since PHP 5.4) a non-issue? Because by that logic it shouldn't Warning is a debugging functionality. Throwing is breaking the app and stopping the whole process. There's a fundamental difference between the two.

Re: [PHP-DEV] PHP 8 is_file/is_dir input handling

Hi! In PHP 7, this returns FALSE: php -r 'var_dump(is_file("ab\0c"));' In PHP 8, the same code throws a ValueException. Problem is now that I think this is a mistake. Exceptions should not be thrown on such values, it only breeds boilerplate code (now you'd have to wrap each call to is_*

[PHP-DEV] Decoding cookie names

Hi! In one of the bug reports there was a question raised - should PHP be decoding cookie names? Right now it does. The standard is pretty much silent on this, and looks like such behavior leads to security problems: https://hackerone.com/reports/895727 However I am not sure whether it's ok

[PHP-DEV] Wiki upgrade?

Hi! Could somebody take care of upgrading the wiki software? It now displays 5 "new release" banners on each page, and it's quite annoying... -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

Hi! > If it adds a micro-optimization, great, but allowing a developer to > explicitly signal intent is the primary argument for adding void. > IMO. You can signal intent by using $_ or $dummy or whatever. You don't need new language construct each time for each way of using or not using a

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

Hi! >> In theory, this should be a general performance win any time one >> needs to iterate over only the keys of an iterable, because it does >> not require the use of an O(n) iteration and building of the array >> that array_keys() would, plus it works on non-array types (such as >> generators

Re: [PHP-DEV] Session mm support

Hi! > I've recently found out that compiling PHP with --with-mm has a massive > negative impact on PHP startup performance (approximately 3-4 times > slower), to the point that our CI got approximately 2x slower overall with > it enabled. This is not great. That's weird. Would be nice to run a

Re: [PHP-DEV] Community vote on RFCs

Hi! > How many people have voting rights? Over 200 if I'm not mistaken? How > many of those have been activly contributing to PHP for over the past > year? I think that's a better question to answer. If half of those > people's voting rights get revoked then maybe there's room to allow a > few

Re: [PHP-DEV] Community vote on RFCs

Hi! > Understandably, the RFC voting process needs to be restricted to carefully > selected people, mostly core developers. But the fact is, this process is a > bit elitist, and fails to represent the community as a whole. A recent PHP development is not a representative democracy. There's no

Re: [PHP-DEV] @@Jit Attribute Considerations

Hi! > Only the trigger mode 4 (attributes) is actually using @@Jit("tracing") and > "function". This trigger mode feels like micro-management for developers > and since it has virtually no spotlight in discussions and blog posts about > the JIT at the moment, we don't know if it brings benefits.

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

Hi! > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? I think it's not a very good idea, and <<>> was just fine, but a lot of folks apparently voted for it. Would be nice to see their opinion and how they answer your concerns. I'm not sure

[PHP-DEV] Re: Including "Disable the ability to use concrete types in PHAR metadata" in PHP 8.0?

Hi! > https://bugs.php.net/bug.php?id=76774 has been open since 2018-08-21. > > That ticket proposes the following: > >> I propose that we disable the ability to have concrete types included in the >> serialized metadata by >> providing an empty classlist to the unserialize call in the PHAR

Re: [PHP-DEV] Improving output of syntax errors

Hi! > For more examples, see: > https://rwec.co.uk/x/php-parse-errors/comparison.html > > The patch can be reviewed at: https://github.com/php/php-src/pull/5722 I think this is great, thanks for implementing it! > I am happy to post a small RFC if people think this requires a vote. > > Any

Re: [PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

Hi! > Better error messages are obviously better than just replacing the name of > the token, however this argument is saying that because this isn't perfect > let's do nothing. I don't think this is the argument. I think the argument is rather than half-fix the problem wrong way, let's fully

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

Hi! > Last, regarding neutrality. This proposal is literally aimed at adopting > more-neutral language. It's not a partisan move to say that harmful > language should be avoided. It is a decidedly political claim that long-time industry standard term with established neutral meaning is

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

Hi! > I was surprised by the many negative responses: Partly just discussing > the term "blacklist" that is perhaps not the main issue. Or telling > people how they should feel and understand words. Nobody tells you how to feel. But when you claim your supposed feelings are the reason to censor

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

Hi! > It is now highly likely that M$ will force changes to these in github > which is probably part of what has prompted the thread. Once 'new If and when this will happen, we'll see the official message from Microsoft/Github and decide how to act. There's no point in discussing such

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

Hi! > I think the time has come for the PHP internals to discuss the use of > master/slave and blacklist terminologies. > As everyone can see, we are going through times of change in the world, see > #blackLivesMatter for example. While your quest for more just and fair world is noble and

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

Hi! > The moment we change blacklist to blocklist, we are essentially > agreeing to the fact that we should censor words because they contain > a color in its name, something that is totally unrelated to any human > race. Are we also gonna change the internal values of the Garbage > Collector for

Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

Hi! >> a) Character count (at line 456, character 23) >> >> b) Quote either the remainder or the parsed section on the line (MySQL >> quotes the remainder, for example) >> >> c) Quote the whole line with an indicator where the error occurred. I'm >> not sure what the best way to do this would be

Re: [PHP-DEV] GitHub FPM label

Hi! > Please could someone add an FPM label to github. FPM is a bit on its own > and the FPM PR's are usually quite independent from other PR's so I think > it would make sense. Mainly it would help me with filtering and keeping > track of FPM PR's. Done:

Re: [PHP-DEV] OSI approval for PHP 3.01 license

Hi! > Would someone mind responding to the original poster on the general > mailing list to let them know that their legal department can rest > assured that the PHP license is OSI-approved. > > The OSI website might not be up-to-date yet, so you can point them to > the following mailing list

Re: [PHP-DEV] A Standard PHAR library included with PHP?

Hi! > One of the primary reasons for many of us — or at least me — to want > more things in core is not listed above, and that reason is: > > - Standardization Core and standardization are completely different things. There are a lot of things in PHP that are being standardized out of core,

Re: [PHP-DEV] [RFC] Function pipe operator

Hi! > https://wiki.php.net/rfc/pipe-operator-v2 Just a small pedantry note - in a comparison section, the RFC compares this syntax to function composition. But this is not function composition. This is a syntax sugar for calling two functions one after another, not operator that produces a

Re: [PHP-DEV] [DISCUSSION] Match expression

Hi! > I'm not quite sure what the way forward regarding that is. I can understand > the reluctance to propose the Rust-style block expression syntax, given its Speaking of which, what is the problem with that? I mean, if we just declare that the value of a block is the return of the last

Re: [PHP-DEV] Resurrecting named parameters

Hi! > 2. Throw a notice if a parameter name is changed. While LSP violations are > normally fatal errors (in PHP 8), we could use a lower-severity diagnostic > for this case, that allows code to still run, but makes developers aware of > the problem. (It should be noted that automatic fixup of

Re: [PHP-DEV] [RFC] Non-capturing catches

Hi! On 4/7/20 6:17 AM, Max Semenik wrote: > Hiya, I'd like to present a new RFC for your consideration: > https://wiki.php.net/rfc/non-capturing_catches > > Briefly, I want to be able to do the following: > > try { > foo(); > catch (SomeExceptionClass) { > bar(); > } Looks good to me.

Re: [PHP-DEV] [RFC] switch expression

Hi! > 1. It uses the same AST, code generation and opcodes as the switch, I > don't agree that it is significantly different than the switch that we > already have. This is reasoning in wrong direction. Nobody cares which opcode it uses. It is significantly different *for the user*, the fact

Re: [PHP-DEV] [RFC] switch expression

Hi! > My recommendation would be to just borrow Rust's keyword: > > $result = match ($var) { > $expression => $expression; > $expression => $expression; > $expression => $expression; > default => $expression; > } Yes, this would be much better idea. -- Stas Malyshev

Re: [PHP-DEV] [RFC] switch expression

Hi! >> I'm still not sure why if we're calling it "switch" > > C# does it. Not to say everything they do is right but it's reassuring > that a big company like Microsoft had the same approach. No it isn't. Having two syntaxes for one keyword is not a good idea, whether Microsoft is doing it or

Re: [PHP-DEV] [RFC] switch expression

Hi! > You can take a look at the tests to get a feel for what it’s like: > > https://github.com/php/php-src/pull/5308/files > > Multiple conditions are possible: > > ``` > > return $day switch { > >     1, 7 => false, > >     2, 3, 4, 5, 6 => true, > > }; I'm still not sure why if we're

Re: [PHP-DEV] [VOTE] Userspace operator overloading

Hi! > I think “as long as it is not overused” are the key words there. We have > a very limited number of internal classes with operator overloading I think the whole point of leaving it to extensions was ensuring it's not overused. And now I see people arguing "well, if it's available to

Re: [PHP-DEV] [RFC] Constructor Property Promotion

Hi! > I would like to submit the following RFC for your consideration: > https://wiki.php.net/rfc/constructor_promotion I like this shortcut. I am not sure though I understand why callable is not allowed? Can't it just create a non-typed property? -- Stas Malyshev smalys...@gmail.com -- PHP

Re: [PHP-DEV] semicolon terminator for switch cases

Hi! On 3/26/20 1:26 PM, David Rodrigues wrote: > I agree with Tovilo. It is weird and confusing. Actually I never know > that it was possible. You seem to contradict yourself - if you never knew it was possible, how could you ever be confused by it? -- Stas Malyshev smalys...@gmail.com --

Re: [PHP-DEV] semicolon terminator for switch cases

Hi! > Maybe something to deprecate in PHP 8.0. > https://wiki.php.net/rfc/deprecations_php_8_0 Why? Whose life it'd make easier? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Class cast

Hi! > Actually it is a simplest case, where only a single information was > considered. But you can expand it to something more complex, where > currently you will need create a static method to copy the data, which > is not a normalized way like cast could do. You can always use anonymous

Re: [PHP-DEV] Class cast

Hi! > 1. Converting from A to B: > > $a = 123; > $b = (Number) $a; // $b is now instanceof Number > > A instanceof Number will created based on $a value. What's wrong with new Number(123)? > 2. Reduce object type (I don't know the technical term): > > class A {} > class B extends A {} > >

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

Hi! > Well a significant part of the purpose of the RFC is to make the case > for why it *should* be done, and the benefits in doing so, and only to And the necessity of making the case also assumes it may, despite all the effort, fail. The community members may remain unconvinced the change

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

Hi! > If a person doesn't have the time or inclination to read into the > details of an RFC, and also doesn't have time or inclination to engage > in discussion about it, and also doesn't have the time or inclination to > give even the briefest of justification about why they are casting their >

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

Hi! > Would it be possible to add a feature when voting were people either > need to type in a one to two sentence reason why they voted "no" on a > proposal OR select from the reasons that others have already given > when voting down the specific RFC? As an optional feature, it might be

Re: [PHP-DEV] Argument with default value

Hi! > As it's arisen on the list again, I've written a note detailing my > view of the previous discussion: > > https://github.com/Danack/RfcCodex/blob/master/explicit_defaults.md As the author of that RFC, I am not particularly sure how it can be "improved", as main argument from what I

Re: [PHP-DEV] Make sorting stable

Hi! > Given that we have internal classes which deliberately have such > comparison behavior (i.e. returning 0 or 1, to signal that there is no > order defined), e.g. Closures[1], I tend to prefer raising a warning > instead of trying to recover. I think there weirdness is because equality and

Re: [PHP-DEV] OSI approval for PHP 3.01 license

Hi! > Bump. Anyone? > > If there are no objections, can someone go ahead and merge this? I merged it. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] OSI approval for PHP 3.01 license

Hi! >>> If this version is approved, will the steward voluntarily deprecate version >>> 3.0, and if not, and if 3.01 is approved, should 3.0 be involuntarily >>> deprecated? > > > The “steward” is the PHP Group. I know that Rasmus, Zeev, and Sascha are > still active on this list, but I

Re: [PHP-DEV] Re: OSI approval for PHP 3.01 license

Hi! > Does anyone here remember why the changes to the license where done in > the first place? The commit was done on the 1st of Jan. 2006 (at least Probably for more clear wording (since outside of context "PHP" can mean many things). Since 3.0 and 3.01 are essentially the same license, I'm

Re: [PHP-DEV] Support rewinding of generators

Hi! > There is a relatively simple (at least conceptually) way to make generators > rewindable: Remember the original arguments of the function, and basically > "re-invoke" it on rewind(). That is provided that: 1. The original arguments of the function can be "remembered" - those can be complex

Re: [PHP-DEV] [RFC] Userspace operator overloading

Hi! > - The individual symbolic operators, with no intrinsic meaning - e.g. > overloading . for concatenation on strings but dot-product for > vectors; or a DSL overloading << and >> for "into" and "out of". Please no. I know it looks fancy and some languages love it, but for a person not in on

Re: [PHP-DEV] [RFC] deprecate md5_file and sha1_file

Hi! > the hash_file() function still supports md5 and sha1 so people that need it > should then migrate to hash_file('md5', ...) or hash_file('sha1', ...) > instead. That was the idea This means spending time and effort to cause extra work to people that already have working code with existing

Re: [PHP-DEV] [RFC] deprecate md5_file and sha1_file

Hi! > I suggest to deprecated the functions md5_file() and sha1_file(). This will Not sure what's the point of it. SHA1 and MD5 didn't change. The recommendations for their usage has changed, but we generally don't use deprecation warnings to improve users' code and recommend them how to

Re: [PHP-DEV] Planning an RFC to allow calls to global functions in constant expressions

Hi! > The constant expressions will be evaluated at the same time php currently > evaluates constant > expressions. But you essentially propose running arbitrary code at that time, which is much bigger deal than evaluating simple constant expressions. While simple functions like strlen() would

Re: [PHP-DEV] Planning an RFC to allow calls to global functions in constant expressions

Hi! > For example, allow `\count()`, `\strlen()`, `\array_merge()`, and > `\in_array()`, > but don't allow functions such as > `\strtolower()` (different in Turkish locale), What happens if a function like strlen() is applied to a non-string argument? Conversion to string is certainly

Re: [PHP-DEV] [RFC] Allow ::class on objects

Hi! > If it could return `string`, that'd be super useful! Would it? There's no class "string". So for all purposes other than printing out, that would be a pretty big footgun. > We have tons of lines of code that look like: is_object($foo) ? > get_class($foo) : gettype($foo) > Getting rid of

Re: [PHP-DEV] What to do with "$array[foobar]"?

Hi! > I think there's two ways to address this. One is to deprecate and > eventually remove the non-wrapped array interpolation syntax entirely, > requiring people to use the generic "{$array['foobar']}" syntax instead. > For the sake of consistency, I think this would also include deprecating >

  1   2   3   4   5   6   7   8   9   10   >