Am 10.05.2024 um 17:51 schrieb Niels Dossche:
Please let me know what you think.
+1
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
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)
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.
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.
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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."
--
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
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
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,
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
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).
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
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
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
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
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.
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
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
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,
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:
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
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,
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
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
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
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
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
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
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
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
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
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:
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
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:
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
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
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
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
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
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
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:
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
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
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.
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
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
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
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
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".
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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) {
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
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
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:
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
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
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
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:
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
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
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
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
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:
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
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:
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
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
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
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:
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
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
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
1 - 100 of 1104 matches
Mail list logo
