Re: [PHP-DEV] Stricter requirements for libxml
Am 10.05.2024 um 17:51 schrieb Niels Dossche: Please let me know what you think. +1
Re: [PHP-DEV] Requiring GPG Commit Signing
Am 02.04.2024 um 16:15 schrieb Derick Rethans: What do y'all think about requiring GPG signed commits for the php-src repository? +1
Re: [PHP-DEV] Consider removing autogenerated files from tarballs
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 release manager generate the files (and the tarball) in a reproducible way?
Re: [PHP-DEV] Re: [PHP-CVS] [php-src] master: Deprecate implicit nullable parameter types (#12959)
Am 14.03.2024 um 15:55 schrieb Matteo Beccati: thanks, I had a quick look in the open issues and didn't find anything. AFAICS, https://github.com/nikic/PHP-Parser/pull/984 has not made it into a release yet. But apart from that there are no open issues on PHPUnit's side.
[PHP-DEV] Re: [PHP-CVS] [php-src] master: Deprecate implicit nullable parameter types (#12959)
Am 14.03.2024 um 14:07 schrieb Matteo Beccati: In my daily CI I have several builds failing today, eg. * PHPUnit 9.6 See https://github.com/sebastianbergmann/phpunit/issues/5719.
Re: [PHP-DEV] [VOTE] [RFC] Final-by-default anonymous classes
Am 15.01.2024 um 11:35 schrieb Daniil Gentili: I've opened voting for the final-by-default anonymous classes RFC: https://wiki.php.net/rfc/final_by_default_anonymous_classes I am confused by the voting option "Make final anonymous classes final by default". You mean "Make anonymous classes final by default", right? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Pre-RFC: Fixing spec bugs in the DOM extension
Am 29.12.2023 um 17:58 schrieb Larry Garfield: I am also on team "yes, let's just do it right." If that means the new classes are only 99% drop ins for the old ones, I'm OK with that. People can switch over when they're ready and do all the clean up at once. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] security email address broken?
Am 28.12.2023 um 19:36 schrieb Robert Landers: I sent an email to secur...@php.net I just sent an email to secur...@php.net and it did not bounce. Of course, that does not mean that it was received. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Final anonymous classes
Am 03.12.2023 um 15:49 schrieb Nikita Popov: For the record, I've voted against this proposal because I believe it should have gone with option 2, that is to *always* make anonymous classes final. I voted "no" for exactly the same reason. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Reproducible Builds
Am 29.11.2023 um 08:12 schrieb Derick Rethans: Not really, as a hash doesn't directly tell me the date/time, and neither would it help in dev branches / checkouts where the latest changes haven't been comiited yet. I do not see how date/time help with seeing what was compiled. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Reproducible Builds
Am 28.11.2023 um 19:40 schrieb Ilija Tovilo: At least for core, enabled-by-default extensions, __DATE__ and __TIME__ seem to be the only variables. I can get reproducible builds by setting SOURCE_DATE_EPOCH. Confirmed: I can get reproducible builds, too, by using CLANG and setting SOURCE_DATE_EPOCH. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Reproducible Builds
Am 29.11.2023 um 07:23 schrieb Sebastian Bergmann: SOURCE_DATE_EPOCH=$(git log -1 --pretty=%cI) should do the trick. What I meant to write was SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct), of course. Sorry for the noise. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Reproducible Builds
Am 29.11.2023 um 01:54 schrieb Marco Pivetta: Also, refs have a timestamp :-) SOURCE_DATE_EPOCH=$(git log -1 --pretty=%cI) should do the trick. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Reproducible Builds
I recently watched a video [1] that once again brought the topic of reproducible builds [2] to my attention. I believe that reproducible builds are becoming more and more important and that the build of the PHP interpreter/runtime should become reproducible. Right now, compiling the same version of PHP's C sources in the same environment (using the same compiler, against the same dependencies, etc.) produces a different binary every time. "Different" meaning that the built artifacts, the "php" executable for the CLI SAPI, for example, are not bit-by-bit identical. One obvious reason why this is the case is the fact that we use __DATE__ and __TIME__ in a couple of places. These preprocessor macros are expanded by the C compiler at compile-time to the current date and time. They are used in sapi/cli/php_cli.c, for instance, so that the output of "php -i" contains the date and time when the executable was compiled. I have not yet checked whether usage of the __DATE__ and __TIME__ macros is the only thing that makes the compilation of PHP irreproducible, but no longer using them would be a good start on the path towards reproducible builds. While we could probably replace __DATE__ and __TIME__ with SOURCE_DATE_EPOCH [3] [4], I cannot help but wonder whether having the date and time when the executable was built in the executable is actually useful. How attached are we to having the date and time of the build in the output of phpinfo(), "php -i", etc.? AFAIK, the topic of reproducible builds was brought up in 2017 for the first, and before this email only, time [5]. There was a PR [6] that was merged into PHP 7.1 which introduced the use of SOURCE_DATE_EPOCH to define PHP_BUILD_DATE in configure.ac. Today, when I grep for SOURCE_DATE_EPOCH on the master branch, I do not find any usage of SOURCE_DATE_EPOCH anymore. Or PHP_BUILD_DATE, for that matter. -- [1] https://media.ccc.de/v/camp2023-57236-reproducible_builds_the_first_ten_years [2] https://reproducible-builds.org/ [3] https://reproducible-builds.org/specs/source-date-epoch/ [4] https://reproducible-builds.org/docs/source-date-epoch/ [5] https://externals.io/message/101327#101327 [6] https://github.com/php/php-src/pull/2965 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Set register_argc_argv to Off by default
Am 07.11.2023 um 11:33 schrieb Thomas Chauchefoin via internals: For instance, the official Docker image has it on [2]. "Official" is relative here. That image is maintained by (the) Docker (community), it is not maintained by the PHP project. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] A new JIT implementation based on IR Framework
Am 21.09.2023 um 11:13 schrieb Tim Düsterhus: Thank you. I find it important to follow the formal process, even if many folks are not able to make a meaningful decision due to the lack of knowledge about the topic. This includes me. I'm in the same boat. My understanding is that even if the new JIT might not (yet) be better than the old one, it is not worse and it is more maintainable. The reactions from more knowledgeable folks were pretty positive overall. That is my understanding as well. So if the new JIT passes the existing test suite without issues, I don't see a reason why the old JIT should not be replaced right away. By immediately removing the old JIT (ideally in a separate commit) the codebase is cleaned up and users that want to test PHP 8.4 (or whatever that version may be in the end) will be forced to also test the new JIT which is probably a good thing. I agree. As a sidenote: most of the teams that I work with use PHP 8 in production. However, none of them use the current JIT. It either caused problems (especially during early PHP 8.0 versions), or does not bring any significant performance improvement. Against that backdrop, I would be interested in whether you, Dmitry or Zend, can share some insight from real-world usage of the JIT. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [IDEA] allow extending enum
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" from enum would be a major backward compatiblity break as it breaks a fundamental assumption about enums. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Constants in traits
On 7/6/22 11:45, Marco Pivetta wrote: I don't want traits to expand in scope I voted NO for this exact reason. From a technical and detail PoV, your RFC is well written and implemented: it just solves a problem that doesn't/shouldn't need solving. Agreed! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] What to do with qa.php.net?
On 7/7/22 18:54, Christoph M. Becker wrote: The only really relevant stuff on the Website is the listing of available QA releases, and the information on how to write PHPT test cases. In my opinion both should be moved to somewhere else (the PHPT docs might go into the php-src repo, and the available QA releases could be listed on php.net). Afterwards I suggest to tear down the Website. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP-8.1 branch seems broken
Am 04.07.2022 um 11:04 schrieb Patrick ALLAERT: I guess that the "1 commit ahead" is just that your local branch is a merge with master. No. If you look at https://github.com/php/php-src/tree/PHP-8.1 right now then you will see "This branch is 1 commit ahead, 7 commits behind master." -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Deprecate dynamic properties
Am 26.11.2021 um 10:06 schrieb Nikita Popov: The RFC has been accepted with 52 votes in favor and 25 against. Has this been merged yet? Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Unified ReflectionType methods
Am 02.10.2021 um 16:37 schrieb tyson andre: `ReflectionType->allowsValue(mixed $value, bool $strict = true): bool` Not having to implement and maintain that functionality in userland would be brilliant and much appreciated. Right now we have https://github.com/sebastianbergmann/type for this for use cases related to test doubles in PHPUnit. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] BC breaking changes in PHP 8.1
Am 23.09.2021 um 18:52 schrieb Nikita Popov: I believe that this continues to be the default behavior of PHPUnit for example. This means that in practice, deprecations do break code, even though they are intended not to. That is correct: by default, PHPUnit converts PHP deprecations, errors, notices, and warnings to exceptions. While disabling the conversion of PHP deprecations to exceptions, for instance, is possible by setting convertDeprecationsToExceptions="false" in your PHPUnit XML configuration file, I do think that the default should be changed to not covert PHP deprecations to exceptions. The next releases of PHPUnit 8.5 and PHPUnit 9.5 will change this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] $this return type
Am 07.09.2021 um 12:28 schrieb Nikita Popov: I have some reservations about this (which basically come down to $this not being a proper "type", so should it be in the type system?) but I can see the practical usefulness, so I think it's worth discussing this. I am not conviced that there is enough value in this to introduce syntax for it, but if at all, then please not "$this" as the name for a type. Off the top of my head, I think that "same" could make sense. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Method compatibility checks and order in which files are included
We noticed that the PHARs of PHPUnit stopped working with PHP 8.1 [1]. Before [2], a commit pushed today, PHPUnit loaded all sourcecode files packaged in the PHAR on startup (to work around problems that (hopefully) no longer exist because PHPUnit's PHAR is scoped using PHP-Scoper nowadays). This loading of all sourcecode files lead to the error reported in [1]. The "static include list" used for this is generated by PHPAB [3] which performs a topological sort based "class implements interface", "class uses trait", "class extends class", etc. dependencies. This topological sort does not, however, consider type declarations for properties as well parameters and return values as dependencies. What follows is a minimal, reproducing example: . ├── autoload.php ├── Collection.php └── CollectionIterator.php 0 directories, 3 files This is the contents of autoload.php: Fatal error: Could not check compatibility between Collection::getIterator(): CollectionIterator and IteratorAggregate::getIterator(): Traversable, because class CollectionIterator is not available in /home/sb/example/Collection.php on line 4 I am using PHP 8.1-dev (590af4678bbdbb9422bfcc568a0b8d2d1a6f74f5). The error does not occur with PHP 8.0.8. I assume the following happens: * The compiler works on Collection.php * The compiler sees that Collection implements IteratorAggregate * The compiler sees that Collection::getIterator() returns CollectionIterator * The compiler performs the method compatiblity check * The method compatiblity check cannot be performed because CollectionIterator has not been compiled yet When I change autoload.php like so then the method compatiblity check can be performed (and succeeds without error). After this long introduction (sorry!), I can finally ask my question: can there be situations where this alternate order of requiring the source files would also fail? Is there a potential for cyclic dependencies between two sourcefiles that can only be resolved when autoloading is used? I am "scared" that using "static include list" may become unfeasible when more compile-time checks such as the method compatibility check are added. -- [1] https://github.com/sebastianbergmann/phpunit/issues/4740#issuecomment-884667189 [2] https://github.com/sebastianbergmann/phpunit/commit/4b5756d8b093d5ae74801586e621703508ec4be1 [3] https://github.com/theseer/Autoload -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate ticks
Am 11.05.2021 um 11:13 schrieb Michał Marcin Brzuchalski: Glad to see this topic. That's a YES I second that emotion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Could we drop the bottom-posting rule?
Am 10.05.2021 um 23:51 schrieb Kamil Tekiela: Could we drop the bottom-posting rule? Please: no. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bugsnet
Am 09.05.2021 um 09:33 schrieb Stanislav Malyshev: 1. Bug reporting template GitHub Issues has support for reporting templates. For instance, clicking "New issue" on https://github.com/symfony/symfony/issues will lead to you https://github.com/symfony/symfony/issues/new/choose. This is an overview of the reporting templates supported by the Symfony project. These templates are managed in version control: https://github.com/symfony/symfony/tree/5.x/.github/ISSUE_TEMPLATE The feature is documented here: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Bugsnet
Am 09.05.2021 um 08:48 schrieb Joe Watkins: Having moved our workflow to github, now seems to be the time to seriously consider retiring bugsnet for general use, and using the tools that are waiting for us - Github Issues. Yes, please. Thank you for proposing this! I propose that we disable bugsnet for all but security issues leaving responsible disclosure method to be handled in some other way at a later date. Leaving bugsnet in a (mostly) readonly mode. We then send a notification to all bugs that were opened against a specific and supported version of PHP, notifying the opener of the change and requesting that they take a couple of minutes to open their issue on github. Sounds reasonable to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] wiki.php.net upgrade
Am 08.04.2021 um 08:01 schrieb Stanislav Malyshev: 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. 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] noreturn type
Am 01.04.2021 um 10:56 schrieb Benjamin Eberlei: I voted no, because i think this should at the maximum be an attribute. This RFC is using the declaration of the return type, to specify that it never returns. As such noreturn or never is a keyword a long the lines of public or final, but it is not a return type. I don't think the argument for potential optimizations in Opcache to eliminate dead code or allow IDEs to hint at dead code are valuable enough to justify this change. Following Benjamin's argument, I have changed my vote to no. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Changes to Git commit workflow
Am 01.04.2021 um 09:58 schrieb Jan Ehrhardt: Will PHP 8.0.4 and 7.4.17 be postponed because of this? They haven't been released yet. The usual day for tagging always was Tuesday or Wednesday. Yes, see https://twitter.com/official_php/status/1377339882645905408 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] noreturn type
Am 10.03.2021 um 19:06 schrieb Matthew Brown: Ondřej Mirtes and I present an RFC for the noreturn type: https://wiki.php.net/rfc/noreturn_type Thank you, Ondřej and Matt, for bringing this up. Makes sense to me, +1. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] noreturn type
Am 11.03.2021 um 07:51 schrieb Peter Stalman: I like this RFC, but I'd like to see the RFC cover if any other languages have a similar return type. The RFC has a "Prior art in other interpreted languages" section. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [DISCUSSION] ReflectionType::accepts
Am 29.01.2021 um 09:18 schrieb Pierre R.: I think this would be a good addition. I personally had to write the exact same algorithm to solve this exact same problem yesterday night. https://github.com/sebastianbergmann/type is the implementation that PHPUnit uses. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode
Am 25.01.2021 um 11:03 schrieb Nikita Popov: Fully support this proposal. Throwing exceptions is the right default, it matches what PDO does, and restoring the old behavior is one line of code. I second that emotion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Documentation is on git
Am 30.12.2020 um 17:17 schrieb Adiel Cristo: Thank you so much for this, Andreas, Nikita, and everyone involved! Hear, hear! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Restrict $GLOBALS usage
Am 04.12.2020 um 11:52 schrieb Nikita Popov: https://wiki.php.net/rfc/restrict_globals_usage Yes, please. The code you found in PHPUnit (both PHPUnit itself as well as sebastian/global-state) that would be affected by this can probably be removed (in a future version of PHPUnit that requires PHP >= 8.1). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate passing null to non-nullable arguments of internal functions
Am 01.12.2020 um 15:57 schrieb Nikita Popov: I've put up an RFC to make the handling of "null" arguments consistent between internal and user-defined functions: Makes sense to me, +1. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] phar command
Am 30.11.2020 um 16:55 schrieb Nikita Popov: My understanding is that packaging libraries as phars is not exactly straightforward, and people use different tooling to achieve that. While I do not use this "phar" command to package my software as PHARs, I use it every once in a while to look inside a PHAR. Don't know whether that justifies keeping it around, though. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Thank you to JetBrains (PHP 8 Announcement page)
Am 27.11.2020 um 16:40 schrieb Sara Golemon: I've been receiving fantastic feedback on the PHP 8.0 Announcement landing page ( https://www.php.net/releases/8.0 ), and I just wanted to extend a big Thank You to all the folks at JetBrains for making this suggestion and putting forth the work on the initial four translations (en, pt_BR, de, and ru). This has helped spread the excitement around this release, and I hope we continue the tradition next year! Hear, hear. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Rename PhpToken::getAll()?
Am 07.11.2020 um 10:09 schrieb Nikita Popov: The reporter suggests to rename it into PhpToken::tokenize() instead, which seems like a sensible suggestion to me. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP 8 release announcement page on php.net
Am 12.10.2020 um 09:56 schrieb Roman Pronskiy: The PHP 8 release is going to be huge, and in some sense, you could say it's a whole new language. There is a feeling that more can be done to promote it more extensively. Agreed! So, the idea is to create a separate release announcement landing page to achieve the following goals: – Promote the release of PHP 8 to the PHP developers – Promote PHP as a modern language, as well as the PHP 8 release, to the general tech audience Alexander Makarov, myself, and Svetlana Belozerova, a designer from JetBrains, have created the following concept: https://i.imgur.com/6fKmTyM.jpg I like the idea as well as the concept you shared. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP 8.0 branch cut
Am 15.09.2020 um 09:24 schrieb Benjamin Eberlei: The options to talk about and use in docs/posts are the following: opcache.jit=yes|true|1 opcache.jit=tracing opcache.jit=function These differentiate the Tracing-JIT from the Function-JIT. Default is tracing. Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP 8.0 branch cut
Am 15.09.2020 um 08:19 schrieb Brent Roose: Is this still on the roadmap? I hope so, too. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Am 04.08.2020 um 15:45 schrieb Derick Rethans: https://wiki.php.net/rfc/shorter_attribute_syntax_change This is probably a wiki/markup issue: the RFC shows "«Attr»" instead of "<>" for the original syntax. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Am 28.07.2020 um 17:50 schrieb Derick Rethans: This is an excellent RFC highlighting the important deficiencies of the @@ syntax. I hope you will all read this and also conclude that we can still pick this better syntax. Remember that it is not only about how it looks. It is much more important that it is functional and causes the least amount of friction in the community. Hear, hear. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
Am 22.07.2020 um 16:45 schrieb Joe Ferguson: We as internals just need to decide that @@ isn't a solution and defer to the next ranked vote? I'd be the first one to +1. Makes sense to me; +1. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
Am 22.07.2020 um 14:00 schrieb Derick Rethans: Please, let's do the sensible and use the Rusty #[...] syntax. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Typed constants
Am 28.06.2020 um 14:35 schrieb Nikita Popov: I do support allowing types for class constants in the interest of overall language consistency. Same here: +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions
Am 16.06.2020 um 10:52 schrieb Nikita Popov: https://wiki.php.net/rfc/namespaced_names_as_token +1 The RFC comes with a small backwards compatibility break related to names that include whitespace, but will hopefully reduce the backwards compatibility impact of future reserved keyword additions. This statement misses the fact that code which uses token_get_all() needs to be updated due to the new T_NAME_* tokens. The RFC itself lists this change, so that's okay. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
Am 11.06.2020 um 00:13 schrieb Sara Golemon: Token names shouldn't show up. Everyone is agreeing with that statement. Universally. Let's fix that problem rather than create new ones by not addressing the underlying issue. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Shorter attribute syntax
Am 09.06.2020 um 17:57 schrieb Theodore Brown:
That's an interesting argument. After thinking about it more, though,
I'm not sure I understand what the benefit would be. The docblock
annotation needed for PHP 7 is *already* forward compatible with PHP 8.
So wouldn't this just be duplicating the attribute and opening the
possibility for them to be out of sync for no benefit?
This would allow the introduction of classes into PHPUnit such as
namespace PHPUnit\Attribute;
#[Attribute]
final class Covers
{
private string $coverageTarget;
public function __construct(string $coverageTarget)
{
$this->coverageTarget = $coverageTarget;
}
// ...
}
that can be used to encapsulate information that may come from a ...
/**
* @covers \Foo\Bar\Baz
*/
... DocBlock-style annotation in PHP 7 but may also come from an ...
#[Covers(Baz::class)]
... attribute when PHP 8 is used.
This would make forward compatibility possible in code such as PHPUnit's
that currently supports DocBlock-style annotations but wants to support
PHP 8 attributes and to deprecate (and later remove) support for
DocBlock-style annotations.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Shorter attribute syntax
Am 09.06.2020 um 13:55 schrieb Benjamin Eberlei:
Larry's suggestion about #[Attr] makes an important argument about allowing
to declare attributes in code in PHP 7 in a forward compatible way that has
not been brought up before.
/** @ORM\Entity */
#[ORM\Entity]
class User {}
This code would work on PHP 7 and 8.
This would be great!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Make sorting stable
Am 12.05.2020 um 16:39 schrieb Nikita Popov: I'd prefer to avoid an extra option. PHP is a high-level language, and the user should not have to concern themselves with sort stability considerations. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Attributes v2 RFC Vote is open
Am 04.05.2020 um 19:34 schrieb Benas IML: I would actually go as far as to say that this is going to be PHP 8 signature feature. It certainly is for me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Unbundle ext/xmlrpc
Am 26.04.2020 um 15:28 schrieb Christoph M. Becker: I propose to unbundle ext/xmlrpc, and written a respective RFC: Makes sense to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] match expression
Am 26.04.2020 um 10:15 schrieb Marco Pivetta: By enforcing only expressions to be on the right-hand-side, we get some nice side-effects too: * no need to discuss `continue` * no need to discuss `break` * no need to discuss `return` Overall, that would be a win-win. Makes sense to me. A point has been risen about the fact that using closures increases memory usage and stack frames: that's a compiler optimization concern, and probably also a minor one, since I'd discourage procedural code on the RHS anyway :-) Agreed. I'd be voting YES on the RFC if the blocks were gone. Same (I think). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] match expression
Am 25.04.2020 um 13:03 schrieb Dan Ackroyd: I like this idea, and would like to see 'match' in PHP. At the same time, is there any need to have the vote right now? The deadline for PHP 8 feature freeze is July 27 2020. There were changes to the proposal overnight, which people have not even had a chance to read, let alone think about. To me it feels like the RFC is being rushed to a vote, with respect to the recent changes and the technical problem you describe. I share this sentiment which is why I voted "no". -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typed array properties V2
Am 21.01.2020 um 22:21 schrieb Matthew Brown: What if we left the array type alone, and instead focussed on "list" type and "dict", "dict" types? That would allow a clear break from previous behaviour, and would allow you to introduce other changes (e.g. removing string -> int coercion for numeric string keys). Just to make sure I understand you correctly: are you proposing new data structures, names list and dict, in addition to array that can bring more specific / strict semantics? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] opcache.jit directive should be split up
Am 14.04.2020 um 15:53 schrieb Sebastian Bergmann: The value for opcache.jit is currently a sequence of four digits, "5021" for instance. This would activate JIT optimizations based on static type inference and inner procedure analyses (Optimization Level), JIT optimization of all functions on load of the respective sourcecode file (Trigger), global linear-scan register allocator (Register Allocation), and AVX instruction generation (CPU-Specific Optimization Flags). Sorry for the noise, but it is more confusing than I thought just a couple of minutes ago. The RFC reads > Consists of 4 decimal digits - CRTO and then lists the individual parts in reverse order (OTRC). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] opcache.jit directive should be split up
PHP 8's JIT is currently mainly controlled through the opcache.jit configuration directive [1]. The value for opcache.jit is currently a sequence of four digits, "5021" for instance. This would activate JIT optimizations based on static type inference and inner procedure analyses (Optimization Level), JIT optimization of all functions on load of the respective sourcecode file (Trigger), global linear-scan register allocator (Register Allocation), and AVX instruction generation (CPU-Specific Optimization Flags). I think that using a single configuration directive for these four distinct aspects of just-in-compilation is a bad idea. Many will, at least at first glance, mistake the value for a bitmask. I think it would be best to split up opcache.jit into five separate configuration directives and propose the following names: * opcache.jit for (de)activating JIT * opcache.jit_optimization_level for setting the optimization level * opcache.jit_trigger for configuring the JIT trigger * opcache.jit_register_allocation for configuring register allocation * opcache.jit_cpu_flags for configuring CPU-specific flags What do you think? -- [1] https://wiki.php.net/rfc/jit#phpini_defaults -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interfaces and ReflectionMethod::isConstructor()
Am 30.03.2020 um 10:14 schrieb Marco Pivetta: Patch makes a lot of sense, but is it done that way to still support 7.x? I'm not sure (don't have a local build of PHP 8.x-dev) if https://wiki.php.net/rfc/remove_php4_constructors is going to come in effect as "PHP4 constructors are finally gone". https://github.com/sebastianbergmann/phpunit/commit/8d399fd561a9a227898fb734c9e89fa1b13d75c8 :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interfaces and ReflectionMethod::isConstructor()
Am 28.03.2020 um 08:44 schrieb Sebastian Bergmann: I can deal with this in PHPUnit's code either way, but need to know what the plan here is. I worked around the issue now [1]. -- [1] https://github.com/sebastianbergmann/phpunit/commit/477798f6b226e830d358bc102cd02bb2e52cfdb2 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Userspace operator overloading
Am 27.03.2020 um 21:10 schrieb Johannes Schlüter: However I don't like this design. [...] Changed my vote back to "no" based on Johannes' arguments. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interfaces and ReflectionMethod::isConstructor()
Am 28.03.2020 um 08:44 schrieb Sebastian Bergmann: isConstructor()); Here is the version of the script for testing with dead versions of PHP: https://3v4l.org/fMCub -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Interfaces and ReflectionMethod::isConstructor()
I recently received a bug report for PHPUnit [1] that with PHP 8 test doubles (test stubs or mock objects) can no longer be created for interfaces that declare a constructor. I was able to reproduce this [2] and learned that PHPUnit's canMockMethod() [3] returns a different result on PHP 8 compared to PHP 7. This is due to the return value of ReflectionMethod::isConstructor() when the ReflectionMethod object was created for an interface. Here is a minimal, self-contained, reproducing test case: isConstructor()); The code shown above yields the following result: * bool(true) for PHP 5.0.0 and PHP 5.0.1 * bool(false) for PHP 5.0.2 through PHP 7.4.4 * bool(true) for PHP 8.0-dev I think that the behaviour in PHP 8 (and PHP 5.0.0 and PHP 5.0.1) is correct. But I also think that constructor declarations have no place in interfaces ... so I am confused. Which is why I did not open a ticket on bugs.php.net and bring this topic to this list instead. To the best of my knowledge, this change in behaviour of isConstructor() between PHP 7 and PHP 8 is not yet documented. If it is intentional and here to stay then it should be documented. I can deal with this in PHPUnit's code either way, but need to know what the plan here is. Thanks! Sebastian -- [1] https://github.com/sebastianbergmann/phpunit/issues/4139 [2] https://github.com/sebastianbergmann/phpunit/issues/4139#issuecomment-605407253 [3] https://github.com/sebastianbergmann/phpunit/blob/9.0.1/src/Framework/MockObject/Generator.php#L861 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Constructor Property Promotion
Am 26.03.2020 um 14:30 schrieb Nikita Popov: I would like to submit the following RFC for your consideration: https://wiki.php.net/rfc/constructor_promotion Looks good to me! Thanks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Userspace operator overloading
Am 24.03.2020 um 11:06 schrieb Sebastian Bergmann: I voted "no" for the same reason. I changed my vote to "yes" because of Nikita's arguments. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Userspace operator overloading
Am 24.03.2020 um 11:03 schrieb Marco Pivetta: Just posting here why I voted "no": it is not your implementation proposal, but rather the concept per-se that IMO shouldn't land in the language. I voted "no" for the same reason. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Attributes v2
Am 09.03.2020 um 20:16 schrieb Matthew Brown: I think the syntax here looks great, and I think this would be an exciting addition to the language. I want to build things with it! I could not have written better words :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Typed array properties V2
Am 17.01.2020 um 08:50 schrieb Aran Reeks: @returns []int int[] etc. is common-place, but I have never seen []int. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Warn when declaring required parameter after optional one
Am 09.01.2020 um 13:31 schrieb Sebastian Bergmann: I would prefer erroring out over just emitting a warning. What I meant, of course, was deprecation (or warning) first before erroring out. Sorry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Warn when declaring required parameter after optional one
Am 09.01.2020 um 13:26 schrieb Nikita Popov: What do you think? I would prefer erroring out over just emitting a warning. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exit() via exception
Am 11.10.2019 um 13:05 schrieb Nikita Popov: Depending on the implementation, we could also allow code to actually catch this exception, which may be useful for testing scenarios, as well as long-running daemons. This sounds interesting :) Anyone have thoughts on this matter? I think \Throwable should always include all objects that can be used with throw and catch. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Object Initializer
Am 13.09.2019 um 15:23 schrieb Matthew Brown: Though this is truly a stylistic complaint, I think it will lead to harder-to-analyse code. Fully agreed, and not just harder-to-analyse for a static analysis tool but also for humans that read the code. -1 from me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters
Am 13.06.2019 um 18:48 schrieb Nikita Popov: An update on this: The last part of covariance support has landed [1] a few days ago and is part of 7.4 alpha 1. As already described, full variance is only supported in conjunction with autoloading. When working in a single file or with explicit includes, the requirement that classes need to be declared before being referenced (including reference in variant type declarations) remains. Does "only supported in conjunction with autoloading" mean that covariance is not (completely) supported when preloading is used? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] High performance function autoloading
On 5/20/19 8:45 PM, Marco Pivetta wrote: Disabling function mocking is good ©️ It was a terrible practice in first place, and it is usually done for impure functions that should be wrapped in integration-tested adapters. Hear, hear :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Type Casting Reloaded
Am 22.04.2019 um 23:47 schrieb Benjamin Morel:
These combine into a third advantage: readability. Today's equivalent of
the above one-liner could be:
/** @var EmailService $service */
$service = $diContainer->get('email.service');
if (! $service instanceof EmailService) {
throw new TypeError('Expected instance of EmailService, ...');
}
Today's equivalent is, at least for me, is this one-liner:
assert($service instanceof EmailService);
This way the IDE knows what type $service is supposed to be and there will
be an exception at runtime (given the appropriate configuration) when this
is not the case.
Personally, I prefer hand-written factories that have an explicit
createEmailService() method with a :EmailService return type declaration,
for example, over the implicitness of a dependency injection container as
the latter disguises and obscures dependencies.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Always generate fatal error for incompatible method signatures
Am 09.04.2019 um 10:25 schrieb Nikita Popov: A small cleanup RFC for PHP 8: https://wik +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] [Result] JIT
Am 29.03.2019 um 10:01 schrieb Joe Watkins: Thanks for all your hard work on this, thanks also to Anatol for making Windows and ZTS happen. Hear, hear. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Abolish Short Votes
Am 21.03.2019 um 19:20 schrieb Joe Watkins: This seems like another no-brainer to improve and clarify the voting process. As with abolishing narrow margins, I'm focused on this one detail and wider discussion of how we may improve other parts of the voting RFC is not appropriate in this thread: We either have a consensus that this detail should be changed or we don't, we do not need to discuss any other details here. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 7.4 Release Manager Selection
Am 19.03.2019 um 17:43 schrieb Joe Watkins: At least I'd like someone to explain in detail why we should extend support for 7.4? Seconded. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Fixed bug #75113: Added DatePeriod::getRecurrences() method.: NEWS ext/date/php_date.c ext/date/php_date.h ext/date/tests/DatePeriod_getter.phpt
Am 17.03.2019 um 19:37 schrieb Derick Rethans: Commit:6eb83a63e1833f0991af4c5533269c8af96c Author:Ignace Nyamagana Butera Tue, 26 Feb 2019 21:21:46 +0100 Committer: Derick Rethans Sun, 17 Mar 2019 14:37:35 -0400 Parents: f167b06d4c86c96291c21c027ba3cae22f5b5be8 Branches: PHP-7.2 PHP-7.3 PHP-7.4 master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=6eb83a63e1833f0991af4c5533269c8af96c Log: Fixed bug #75113: Added DatePeriod::getRecurrences() method. Why is new functionality added to PHP 7.2 and PHP 7.3? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Merging new hash algorithm (crc32c) into PHP 7.3 and maybe 7.2?
Am 11.03.2019 um 15:20 schrieb Derick Rethans: don't forget the PHP-7.4 branch, which is *not* master (master is 8.0). Nikita already merged it into PHP-7.4 and master. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Merging new hash algorithm (crc32c) into PHP 7.3 and maybe 7.2?
Am 10.03.2019 um 21:12 schrieb Gabriel Caruso: As both PHP 7.2 and 7.3 has been out for a while, -1 on this one. Same here; no new functionality should be added to already released versions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 7.4 Release Manager Selection
Am 06.03.2019 um 01:18 schrieb Gabriel Caruso: I'd like to suggest Peter Kokot for this role. Seconded. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] New custom object serialization mechanism
Am 01.03.2019 um 16:08 schrieb Nikita Popov: I have opened voting on https://wiki.php.net/rfc/custom_object_serialization. The vote will be open until 2019-03-15. I voted "No" because this adds a third mechanism without a concrete plan to phase out the existing two mechanisms. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Weakrefs
Am 26.02.2019 um 21:37 schrieb Marco Pivetta: Just posting to clarify on my "No" vote: I am generally against having more features that (by design) introduce spooky action as a distance behavior, especially on references. I voted "No" for similar reasons. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change default branch in GitHub for php-src
On 2/22/19 7:00 PM, Gabriel Caruso wrote: So, I'd like to propose that the default branch should be *`PHP-7.4`*. Makes sense to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] wiki.php.net
Who is in charge of wiki.php.net and updates for its software? I ask because every time I am (logged in) on that site I see warnings such as Hotfix release available: 2018-04-22b "Greebo". upgrade now! Hotfix release available: 2018-04-22a "Greebo". upgrade now! New release available: 2018-04-22 "Greebo". upgrade now! Hotfix release available: 2017-02-19f "Frusterick Manners". upgrade now! I don't know if any of these updates are critical but maybe the software should be updated anyway? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] JIT
Am 31.01.2019 um 18:08 schrieb Derick Rethans: I do not believe that something major like this should make it into any PHP 7.x release. Having it as experimental new feature in the master/PHP 8.0 branch makes the most sense to me. ACK -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Missing param in arginfo_pdostatement_setfetchmode: ext/pdo/pdo_stmt.c
Am 14.02.2019 um 08:13 schrieb Gabriel Caruso: Commit:ad75511c8e5461cc6ba5cf7aad8f5265615560a8 Author:Gabriel Caruso Fri, 16 Feb 2018 21:29:34 -0200 Parents: d57c56cd6304b92db83180e7939eb6288c3a18af Branches: master Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=ad75511c8e5461cc6ba5cf7aad8f5265615560a8 Log: Missing param in arginfo_pdostatement_setfetchmode PDO::setFetchMode receives up to 3 params Are you sure you only want to add this to master (PHP 8) and not (at least) also to PHP 7.4? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
Am 01.02.2019 um 12:27 schrieb Nikita Popov: I would like to suggest that installation of PEAR is disabled by default in PHP 7.4. PR: https://github.com/php/php-src/pull/3781 +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Old style constructors in PHP-8
Am 30.01.2019 um 12:15 schrieb Pierre Joye: Once officially done, I am sure someone will write code converters as well. The no_php4_constructor fixer of php-cs-fixer has been able to automatically migrate old-style constructors for years. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pear.php.net gives certificate for mail.cweiske.de
Am 29.01.2019 um 14:27 schrieb Ralf Becker: Is that a known problem? Unfortunately yes. Use http://pear.php.net/ and you'll learn why. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal fo "Code-free constructors declaration"
Am 25.01.2019 um 11:44 schrieb Nikita Popov: I think that *if* we want to add some kind of sugar of this type, then I'd strongly prefer the syntax used by Hack than the one proposed here. Agreed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Branch off PHP-7.4 early
Am 24.01.2019 um 15:52 schrieb Nikita Popov: * Create the PHP-7.4 branch now/soon, rather than in summer. * master will be PHP 8.0. * All changes are applied to the lowest applicable branch and then merged up as usual, including to PHP-7.4 and master. * NEWS mentions for bug fixes are only added up to PHP-7.3. They are not added on the PHP-7.4 branch, just like for master. (Excluding changes that are only in 7.4/8.0, of course.) * All feature additions can generally still go to the PHP-7.4 branch, there is no freeze. * Backwards incompatible changes and major internal API changes can go to master (assuming they are accepted through the usual processes). Makes sense to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New custom object serialization mechanism
Am 24.01.2019 um 15:09 schrieb Marco Pivetta: Not really fussed about having another implicit interface for serialization (via magic methods). I second that emotion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Built-in classes that cannot be serialized
Am 26.11.2018 um 13:35 schrieb Nikita Popov: If I can rely on classes to throw an exception when serialize() is performed (be it through zend_class_serialize_deny or in __sleep()) then, yes, I can just try it. I believe you can rely on this. Not on any specific exception type, but the fact that it will throw. Good to know, thanks. I've switched CURLFile, PDO and PDOStatement over to use serialize_deny. I couldn't find other classes in bundled extensions that were manually throwing on serialization. Thanks! that contains a class that cannot be serialized. Serializability is not a property of a single class or object, it's a property of the whole object graph that is being serialized. I know: https://github.com/sebastianbergmann/global-state/blob/master/src/Snapshot.php#L360 ;-) Best, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
