On Fri, 7 Jul 2023 at 18:39, Calvin Buckley wrote:
>
> I'd like to hear any oversights, and what could be done to take this
> further.
I think someone needs to write some code and some tests, and see what happens.
It's possible that PARAM_BINARY could be used across all of the PDO
drivers that
On Tue, 4 Jul 2023 at 20:30, Nuno Maduro wrote:
>
> Hi Internals,
Hi Nuno,
> I believe having a Laravel core team member on the list of members with
> voting rights would be incredibly valuable to the internals team.
All open source projects value contributions to their project really
highly
Hello internals,
I'm opening the vote for the 'PDO driver specific sub-classes' RFC:
https://wiki.php.net/rfc/pdo_driver_specific_subclasses
It will last for two weeks and end on 2023-07-17T17:00:00Z
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Thu, 29 Jun 2023 at 11:40, BohwaZ wrote:
>
> I'm sorry to disagree, but changing this would be a bad idea for
> security.
>
> I'm quite sure that I never want users to be able to load any
> extension through SQL, or it would mean trouble :(
>
> So just like in the SQLite3 extension, extension
On Tue, 27 Jun 2023 at 17:25, Larry Garfield wrote:
>
> The RFC doesn't specify if `new PDO(...)` changes behavior at all.
That behaviour is not changed at all.
> will PDO still have the postgres methods
Yes, until someone does another RFC to deprecate and remove them.
> if someone does [`new
Hi everyone,
Just giving an update on the
https://wiki.php.net/rfc/pdo_driver_specific_subclasses RFC as time is
running out. The RFC text has been updated with the implemented
subclasses stubs.
There are a few small things to note, and one larger thing:
Marc Bennewitz wrote:
> It would be
Hi internals,
I'm now opening the discussion for the Closure self-reference RFC:
https://wiki.php.net/rfc/closure_self_reference
This was previously discussed as a draft here:
https://externals.io/message/112216#112216
Thank-you to KapitanOczywisty for the implementation.
cheers
Dan
Ack
--
On Mon, 22 May 2023 at 22:32, David Gebler wrote:
>
> either you use static analysis tools as part of your PHP workflow, because
> you care about that stuff, or you don't.
I these words imply an unpleasant connotation; that people who don't
use static analysis tools are bad people who don't
On Sat, 20 May 2023 at 18:58, David Gebler wrote:
>
> this is exactly the kind of check which you would
> expect to be done at the static analysis stage
Even for those who use static analysis, most (afaik) don't have it
running constantly in local development and this RFC would prevent
people
On Thu, 18 May 2023 at 09:12, Marco Pivetta wrote:
>
> I am not sure this RFC is really relevant... Would it perhaps
> make sense to have this in userland first, in phpstan or psalm
> plugins, to see if there is interest?
The RFC lists other languages where an equivalent is available, and we
can
On Sun, 21 May 2023 at 06:16, Marc wrote:
>
> Do you think this could be an acceptable BC-break
No. Suggesting changing a 30 year old maths operations is a huge BC break.
> or should this be a different function?
Just make your own that does precisely what you want...
cheers
Dan
Ack
--
PHP
On Thu, 11 May 2023 at 17:37, Tim Düsterhus wrote:
>
> Hi
>
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
>
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
This RFC is probably a good idea, even if the number of
On Sat, 13 May 2023 at 00:08, Larry Garfield wrote:
>
> I am actually tempted to propose that we do deprecations at the very
> start of a release, 9.0 and 9.1 only, and then not allow them for the
> rest of that major, for that exact reason.
That sounds really unwise.
People aren't that
On Sat, 13 May 2023 at 00:08, Larry Garfield wrote:
>
> That means it's impossible to write code that works from 8.2 to 9.0 without
> version checks. The overlap period is only 2 releases (8.3 and 8.4). That's
> too short of a window.
That it is too short, is an opinion.
Having one version
On Sun, 14 May 2023 at 22:59, Hans Henrik Bergan wrote:
>
> I'm not sure there is an English version at all
For me, there is an English version below the German version, Er, and
apparently for you also:
https://phpimagick.com/deutsche_uber_englisch_2.png
> my Accept-Language doesn't mention
On Sat, 13 May 2023 at 08:27, Robert Landers wrote:
>
> Hello Internals,
>
> It is with much trepidation and excitement that I'd like to announce
> the `nameof` RFC (https://wiki.php.net/rfc/nameof).
Can you provide more details on what the error conditions are? I can
see 'non-existent static
On Thu, 11 May 2023 at 10:36, Tim Düsterhus wrote:
>
> I believe this vote format ("three options") is not really compatible
> with the voting rules (https://wiki.php.net/rfc/voting).
>
> For example it's not entirely clear what would happen here:
>
> 5 votes to deprecate in 8.3 / remove 9.0
> 4
On Thu, 11 May 2023 at 10:36, Tim Düsterhus wrote:
>
> Would it be an option to just deprecate everything in PHP 8.3
As I said before, having at least one version where the new versions
of the functions are available, and the old versions aren't giving
deprecation notices, is the 'cleanest' way
On Tue, 7 Jun 2022 at 15:25, Philip Hofstetter
wrote:
>
> On 6 Jun 2022 at 21:15:12, Dan Ackroyd wrote:
>>
>> 2. Other than the SQLite blobOpen functionality, does anyone know of
>> any other functionality that is exposed by SQLite or Postgres that
>> isn't curre
>From the RFC:
>
> Code which invokes get_class() without parameters should be modified to
> use __CLASS__ or get_class($this) instead,
I don't think the first option is equivalent:
class C {
function printType() {
echo "__CLASS__ is " . __CLASS__ . "\n";
echo "get_class is "
Kamil Tekiela wrote:
> > I think one year of deprecation is not enough... It doesn't make
> > sense to me to add a replacement but not deprecate the old variant.
Máté Kocsis wrote:
> Yes, this upgrade path also makes sense to me, and I'm happy to go with
> it if others don't disagree!
For the
On Mon, 1 May 2023 at 12:21, Jakub Zelenka wrote:
> It seems that in the current definition, the RFC is just for blocking
> rejected features to get to the next release rather than requiring accepted
> features to be in the next releaseIt means it requires some
> sort of consensus between
On Thu, 20 Apr 2023 at 18:25, Larry Garfield wrote:
>
> Hi folks. This is a pre-discussion, in a sense, before a formal RFC.
Hi Larry,
The "Allow casting closures into single-method interface
implementations" one seems a complete non-starter, as that seems
really hard to work with. You'd have
On Thu, 13 Apr 2023 at 11:39, Jordi Boggiano wrote:
>
> On 2023-04-12 22:26, Rowan Tommins wrote:
> > I could just about live with that example changing so that the
> > fallback was cached, but I definitely don't think an explicit call
> > like \foo\strlen('x') should become an implicit alias for
On Mon, 10 Apr 2023 at 14:01, Ondřej Mirtes wrote:
>
> I don’t like the proposed function names:
I think we're going to leave thinking about changing the names until
the end of the discussion.
They don't really matter, and it probably would be better to avoid
clogging up the technical
Hi Internals,
If anyone is looking for help either developing extensions or work on
internals/PHP core then the PHP chat room ('Room 11' aka R11) on
StackOverflow quite often has some internals contributors lurking
around, waiting for interesting conversations to take part in:
On Thu, 13 Apr 2023 at 07:30, Robert Landers wrote:
>
> This has been brought up a couple of times, but I can't seem to find
> it.
https://externals.io/message/119392
https://externals.io/message/120011
> I don't think something like this is possible with the current
> implementation of
On Wed, 12 Apr 2023 at 17:32, Claude Pache wrote:
>
> The proposed modification of `function_exists()` will break existing code:
Please can you submit a failing test to
https://github.com/Girgias/php-src/tree/zend_autoloader that shows a
BC break.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime
On Tue, 11 Apr 2023 at 18:12, Hans Krentel via internals
wrote:
>
> So I'd love to see some commentary on a `function_alias()`
> if now function autoloading is considered to come in
I wouldn't be opposed to it, but it should be a separate RFC.
The implementation could be copied from
On Wed, 12 Apr 2023 at 09:24, Nicolas Grekas
wrote:
>
> I would like to see a similar benchmark with function autoloading enabled.
> https://github.com/phpbenchmarks/
Can you point me to where one can tell the benchmark framework to use
a custom version of PHP?
> One of the big differences
On Tue, 11 Apr 2023 at 08:14, Michał Marcin Brzuchalski
wrote:
>
> Can we improve the RFC with a short description of issues on SPL autoload
> this RFC tries to address?
Sure, if you want to propose some clearer words than these:
"The spl_autoload_register() does not become an alias for
On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
>
> Similarly, I think it should be possible to "unpin" a function
> lookup with a later definition,
Can you say what the technical justification for that is?
There's reasons why (imo) it's probably wrong, but I don't currently
understand what
Hi Rokas,
On Thu, 30 Mar 2023 at 08:36, Rokas Šleinius wrote:
>
> On Wed, 29 Mar 2023 at 18:40, Larry Garfield wrote:
> >
> > 1) Please don't top-post.
>
> Am I doing it right now? I've never been on a mailing list.
You're replying in the preferred manner, yes. Quoting only the needed
amount
On Tue, 14 Mar 2023 at 16:58, Larry Garfield wrote:
>
> New engine approach first, then syntax based on what that approach allows.
Would it be desirable to split those two things into two separate
RFCs, by having the first RFC not have native syntax support, but
instead another static method on
Hi Mark,
On Sat, 4 Feb 2023 at 00:22, Mark Niebergall wrote:
>
> This is also a bigger policy question for other seemingly-abandoned
> RFCs. If it is agreed that a new RFC should be created in this scenario,
I've added some notes on the page https://wiki.php.net/rfc/howto
I had some words
On Mon, 23 Jan 2023 at 16:27, Nicolas Grekas
wrote:
>
> Legit concerns. I'm going to prepare a more extensive use case so the
> motivations of RFC become more obvious.
>
> I'll get back on this thread when ready. Stay tuned :)
Please can you look at implementing it as a function, that returns a
On Mon, 23 Jan 2023 at 23:03, Larry Garfield wrote:
>
> So you're saying that would generate a callable equivalent to:
>
> $fnMethod = fn (Zok $zok, string $zebranky): Frungy => $zok->Pik($zebranky);
Yes.
> (We're also now rather far afield from the OP's request, I think.)
Well, yeah.
On Mon, 23 Jan 2023 at 20:51, Larry Garfield wrote:
>
> On Mon, Jan 23, 2023, at 12:32 PM, Dan Ackroyd wrote:
>
> >
> > $fnConstructor = Closure::fromClassConstructor(Zoq::class);
> > // signature of $fnConstructor is the same as `function(Fot $fot): Zoq`
> &
On Sun, 22 Jan 2023 at 17:45, Ollie Read wrote:
>
> Hello all,
Hi Ollie,
> I've created a feature request issue on GitHub (here:
> https://github.com/php/php-src/issues/10414), but I have been advised that
> it's best to post here.
> ...
> I think we could delay the error until the closure
Hi Juris,
On Fri, 20 Jan 2023 at 14:26, Juris Evertovskis wrote:
>
> Hey, internals!
>
> As many before me, I have come accross a need to load a SQLite extension.
>
> - The community does not want a new driver-specific `loadExtension` method
> on the PDO class (there are some historical
On Fri, 25 Nov 2022 at 00:07, Larry Garfield wrote:
>
> On Sun, Nov 20, 2022, at 7:20 AM, Dan Ackroyd wrote:
> > Hi Larry,
> >
> > Regarding the syntax, up until now PHP has only supported the letters
> > a-z and underscore in keywords.
> >
> > I realis
On Sat, 10 Dec 2022 at 10:06, Robert Landers wrote:
>
> However, I generally feel that the program will always have access to
> the raw data, after all, it is unserializing it.
Not always in a useful way.
function getMeeting(DB $db, int $meeting_id): Meeting
{
$meeting_data =
On Sun, 18 Dec 2022 at 16:48, Theodore Brown wrote:
>
> why it's okay to make a BC break for the OO API,
> but not for the procedural API.
Because they are different APIs.
People who use OO apis are used to handling exceptions and would
expect failures in OO code to throw exceptions. That the
On Thu, 8 Dec 2022 at 15:05, Tim Düsterhus wrote:
>
> If your data fails to
> unserialize, the only safe option is to throw it away.
Even given that, you probably want to investigate how it got corrupted
so that you can stop it from happening again. And doing that would
rely on being able to see
On Tue, 29 Nov 2022 at 17:41, Derick Rethans wrote:
>
> I have just published a new "More Appropriate Date/Time Exceptions" RFC
>
>
> Comments?
>
None of the 'Invalid serialization' errors tell the programmer who
reads them what is wrong with the data.
Unless the code was written in such a way
Hi Larry,
Regarding the syntax, up until now PHP has only supported the letters
a-z and underscore in keywords.
I realise this is an aesthetic thing, but "private(set)" looks like a
function to me, and not a keyword. I saw the previous poll, and it
didn't include options for either
Hi Pedro,
On Mon, 24 Oct 2022 at 19:06, Pedro Nacht via internals
wrote:
>
> Hey Jordan,
You seem to have responded to Jordan's tech questions, but I was
really hoping for an answer to my more fundamental questions:
Danack wrote:
> What is the morality of open source?
> What is the morality
Hello Pedro.
On Thu, 20 Oct 2022 at 23:26, Pedro Nacht via internals
wrote:
>
> I'm happy to answer any questions anyone might have
What is the morality of open source?
What is the morality of encouraging people to contribute to open source?
When people see open source projects being abused
On Wed, 19 Oct 2022 at 19:11, Tim Düsterhus wrote:
>
> While the behavior would in fact change, it would not introduce a
> "security issue" if this what you were hinting at.
No, just that it would break in production, and then have to be fixed
after a live site was already affecting end-users.
Hi Tim,
On Fri, 14 Oct 2022 at 15:44, Tim Düsterhus wrote:
>
> Hi
>
> as announced on Wednesday [1] I've now opened the vote for:
>
> "Improve unserialize() error handling" [2]
I'm going to have to vote no for changing to throwing an exception.
The BC break is too big imo, and too hard for
Hello Joshua,
> Shall an option be added to getFloat() that changes the logic to
select from [$min, $max] (i.e. allowing the maximum to be returned)? And
how should that look like? Boolean parameter? Enum?
An enum would probably be nice, and possibly be for all four cases of
On Sat, 15 Oct 2022 at 13:14, Gianni Gentile
wrote:
>
> What are your thoughts on introduce the `(AnyType)` cast to instantiate
> objects from associative array (or object properties also)?
It seems a pretty bad idea.
In particular, it makes for hard to maintain code as it doesn't give a
place
Hi Tim,
On Wed, 14 Sept 2022 at 17:59, Timmy Almroth wrote:
>
> Hello everyone. I would like to announce that the RFC for "StreamWrapper
> Support for glob()" is now ready for Discussion.
The RFC has:
> Final patch will be produced ... if this RFC is approved.
I think that although the RFC
Hi Nicolas,
On Thu, 8 Sept 2022 at 18:06, Nicolas Grekas
wrote:
>
> There needs to be serious justification for it.
I think this is covered by the RFC.
The current behaviour where people have to setup a custom error
handler, and then restore the previous error handler, is pretty
'ungood'.
The
Hi Paul,
On Sat, 10 Sept 2022 at 12:04, Paul Dragoonis wrote:
>
> Welcome, Tim :-)
>
> Do give it more thought regarding the callbacks what Nikolas
> said, sleep on it.
Although welcoming people is nice, you might want to check that they
haven't already had two RFCs passed, and become the
On Fri, 1 Jul 2022 at 15:05, Larry Garfield wrote:
>
> The vote for auto-capture closures is now open. It will run until 15 July.
Voting no as:
i) changes in the implementation need more than 1.5 hours discussion
between that change and the voting opening.
ii) The inconsistency of capturing
Antoine wrote:
> It could be beneficial for the whole ecosystem to have as well exceptions
> type hint.
Here are my short notes on the topic.
https://github.com/Danack/RfcCodex/blob/master/throws_declaration.md
tl:dr someone probably needs to come up with a strong reason for why
it would be a
Hi Rowan,
Rowan wrote:
> For that to work, it would require the variable to be captured by
> reference, not value.
> ...
> The only way for it to work would be using capture by reference (not
> supported by the proposed short syntax):
I wrote about this before. Some of the words in the RFC are,
On Wed, 29 Jun 2022 at 18:30, Larry Garfield wrote:
>
> The conversation has died down, so we'll be opening the vote for this
> tomorrow.
I think I've just thought of a problem with the optimization bit of
'not capturing variables if they are written to before being used
inside the closure'.
Hi Nicolas,
On Fri, 24 Jun 2022 at 17:38, Nicolas Grekas
wrote:
>
> I'm now considering withdrawing the RFC because I don't see a way forward
> that could be consensual enough.
Just in general, I think changes to the type system are always going
to take longer than a few weeks to discuss.
Larry Garfield wrote:
> "Create all DB sub-classes?" - I'd say they all should have subclasses, even
> if empty. It's more consistent* that way, and you can then also rely on
> instanceof giving you useful information rather than "well, it's not one of
> the special ones, so beyond that, NFI."
On Tue, 21 Jun 2022 at 10:41, Rowan Tommins wrote:
>
> The implementation MUST be written by
> someone with intimate knowledge of the DBMS in question, or it cannot be
> trusted.
Well, that rules me out of doing it.
> So if we only have a Postgres implementation right now, we should either
>
On Tue, 21 Jun 2022 at 02:26, Larry Garfield wrote:
>
> Any chance I could convince you to move away from the DSN for the factory?
No. That sounds like a challenge for someone who knows about (and
cares about) that problem. There's also not enough time to have that
discussion before feature
Hi,
Following previous discussions, here is an RFC to have DB specific
classes for PDO.
https://wiki.php.net/rfc/pdo_driver_specific_subclasses
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Mon, 20 Jun 2022 at 22:26, Pierrick Charron wrote:
>
> If you plan to submit a RFC you have
> until July 5th to open it for vote so that it can be closed on time.
Does that mean tomorrow midnight, or midnight today (aka in about 30
minutes time), is the last chance for RFCs to be announced as
Hi Larry, Arnaud,
On Mon, 13 Jun 2022 at 13:57, Arnaud Le Blanc wrote:
>
> Auto-capture in PHP is by-value. This makes this impossible. It also makes
> explicit declarations non-necessary and much less useful.
>
Separating off some pedantism from the hopefully constructive comment,
I think
Hi Arnaud,
Arnaud Le Blanc wrote:
>
> Following your comment, I have clarified a few things in the "Auto-capture
> semantics" section. This includes a list of way in which these effects can be
> observed. These are really marginal cases that are not relevant for most
> programs.
Cool, thanks.
On Thu, 9 Jun 2022 at 17:34, Larry Garfield wrote:
>
> That RFC didn't fully go to completion due to concerns over the performance
> impact
I don't believe that is an accurate summary. There were subtle issues
in the previous RFC that should have been addressed. Nikita Popov
wrote in
On Mon, 6 Jun 2022 at 22:10, Benjamin Morel wrote:
>
> Hi, what about the ability to load an extension on SQLite?
> https://bugs.php.net/bug.php?id=64810
> Basically the equivalent of SQLite3::loadExtension()
Thanks, that's exactly the type of thing that should be looked at being added.
>
Hi,
I'm looking at making an RFC for subclassing PDO to expose database
specific methods in a less magic way, aka implementing what was
discussed here: https://externals.io/message/100773#100813
I have two questions for people who use the PDO with SQLite or Postgres
1. Are any of the functions
On Sun, 29 May 2022 at 16:34, Dan Ackroyd wrote:
>
> *an incorrect name*
Apologies for writing your name incorrectly. That should of course
have been addressed to Juliette.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.p
Hi Julie,
On Sat, 28 May 2022 at 09:22, Juliette Reinders Folmer
wrote:
>
> I admit, I puzzled over this for a little and wanted to take the time to
> respond properly before opening the vote, so I'm delaying the start of the
> vote until beginning of the upcoming week.
Cool.
Actually, I've
Hey Julie,
On Thu, 26 May 2022 at 12:45, Juliette Reinders Folmer
wrote:
>
> I propose to open the vote on this RFC tomorrow.
Before you open the vote, please could you split the voting into two,
one for the is_callable, and one for the callable type check?
Rowan wrote in
On Mon, 16 May 2022 at 16:06, Andreas Leathley wrote:
> I have created a preliminary
> implementation and an RFC for making implicit boolean type coercions
> more strict:
>
> https://wiki.php.net/rfc/stricter_implicit_boolean_coercions
>
> With this email I'm starting the two week discussion
Hi Rox,
On Mon, 23 May 2022 at 15:49, ROX wrote:
>
> I focus on Developer eXperience and language consistency.
When you have karma to write the RFC, you should probably include in
the text why having an extra piece of capability in the language (i.e.
one more thing to learn), that only saves
Hi Victor,
I have strong feelings about the war and that people should be taking
whatever personal action they can (check my pinned tweet, @MrDanack),
but:
i) PHP Internals is for discussion of PHP internals.
ii) We have contributors on both sides of the conflict. There are also
many other
On Thu, 24 Feb 2022 at 14:11, Tim Düsterhus, WoltLab GmbH
wrote:
>
> I see two possible options to remediate this issue:
>
> ---
>
> 1. Disallow both serialization and unserialization.
>
> This will make the serialization issue very obvious, but will require
> adjustments to exception
On Tue, 11 Jan 2022 at 09:11, Tim Düsterhus, WoltLab GmbH
wrote:
>
> So basically all the other languages I researched do not provide
> arguments within back traces.
Uh, that kind of suggests that providing arguments at all is a
mistake, and that removing could be the way to go. I mean other
Hi Tim,
On Mon, 10 Jan 2022 at 14:05, Tim Düsterhus, WoltLab GmbH
wrote:
>
> this is a follow-up for my "Pre-RFC" email from last Friday, January, 7th.
>
> https://wiki.php.net/rfc/redact_parameters_in_back_traces
>
How do other languages handle this problem? Or how do they avoid it in
the
On Fri, 17 Dec 2021 at 18:36, Stanislav Malyshev wrote:
>
> When reading
> this code: $foo * $bar - how do I know which of the ways you took and
> where should I look for the code that is responsible for it? When I see
> $foo->times($bar) it's clear who's in charge and where I find the code.
>
On Thu, 16 Dec 2021 at 08:24, Pierre wrote:
>
>
> If the names are a problem, why not registering those using an attribute
> ?
If there is a strong reason to use attributes, then the argument
should start from there.
Starting from "well we could just use an attribute" and then putting
the
On Thu, 16 Dec 2021 at 12:21, Andreas Hennings wrote:
> Methods and functions have searchable and clickable names. Operators don't.
> The "searchable" applies to grep searches in code, but also google
That's one of the reasons why I prefer a magic methods based approach.
function __plus(...){}
On Sat, 11 Dec 2021 at 19:13, Jordan LeDoux wrote:
>
> I *think* that all of the things you mentioned will need similar
> updates to work correctly with this RFC even if it was done
> with plain old magic methods instead.
No, that's not true. Codesniffer and all the other tools parse magic
On Sat, 11 Dec 2021 at 17:46, Larry Garfield wrote:
>
> Using symbols, however, would (with some future extension to make it
> extensible) allow for:
I don't get how it's easier, other than being able to skip naming the
symbol name. e.g. adding union and intersection operators
function
On Sun, 12 Dec 2021 at 08:55, James Titcumb wrote:
>
> The only mitigation for unnecessary complexity I can think of is to force
> overloaded operators to be "arrow functions" to encourage only minimal
> code, e.g.
>
The 'valid' use-cases for this aren't going to minimal pieces of code.
Things
Hi Jordan,
On Thu, 9 Dec 2021 at 20:12, Jordan LeDoux wrote:
>
> Hello internals,
>
> I last brought this RFC up for discussion in August, and there was
> certainly interesting discussion. Since then there have been many
> improvements, and I'd like to re-open discussion on this RFC.
In general
On Wed, 8 Dec 2021 at 16:02, Jeremy Mikola wrote:
>
>
> We haven't explored using stubs, but I'll keep that in mind. ...
> (which we plan to do since we finally dropped support for PHP
> 7.1).
>
FYI, the stub files maintain #ifdef info through their processing,
which allows some useful
On Thu, 9 Dec 2021 at 19:28, Dan Ackroyd wrote:
> > Is this intentional? If so, could someone explain the purpose of the
> > change?
>
> Probably to make the build process less flaky, by explicitly checking
> dependencies, so that there are fewer instances of "stuffs
On Wed, 8 Dec 2021 at 15:25, David Zuelke via internals
wrote:
>
> That doesn't work with PHP 8.1 anymore - the Makefile generated by
> phpize now contains an include directive at the top level (near the
> bottom), e.g.:
>
> -include src/php_raphf_api.dep
The file src/php_raphf_api.dep is
On Fri, 26 Nov 2021 at 00:55, Brady Wetherington via internals
wrote:
>
> That's 1.5 million hours, which is 171 developer-years.
If we're going to imagine numbers; there are 6 million PHP developers
in the world*. If on average they each lose just 1 hour per year by
making typos and
Hi Juliette,
On Mon, 15 Nov 2021 at 23:36, wrote:
>
> I've been asked to post the link to the Twitter discussion in this
> thread for visibility.
>
> The Twitter thread generated, and is still generating, quite a lot of
> discussion,
I'm not going to quote from the Twitter thread partly as lot
On Fri, 12 Nov 2021 at 19:00, Matthew Weier O'Phinney
wrote:
>
> Our IDEs, coding standards, and static analysis tools can already flag
> these things for us, helping us catch them early. Hell, unit testing will
> find these for us, when a test fails due to a value not being set in a
> property
On Thu, 25 Nov 2021 at 05:05, Tim Starling wrote:
>
> Voting is now open for my RFC on locale-independent case conversion.
>
It seems popular, and likely to pass, but I voted no as the "Backward
Incompatible Changes" section is missing which makes it hard to
evaluate the impact.
cheers
Dan
Ack
On Tue, 23 Nov 2021 at 10:43, Kim Hallberg wrote:
>
> For GitHub sponsors the organisation, in this case PHP, would need to connect
> a
> bank account directly to the organization.
I believe Nils is referring to this:
https://blog.opencollective.com/double-the-love/
Sara wrote:
> An
On Mon, 15 Nov 2021 at 09:47, Derick Rethans wrote:
Derick wrote:
> I think it is a mistake to decide on a whim to move over to GitHub
> issues without having evaluated anything else.
Maybe avoid being insulting about other people's decision making
process? I'm pretty sure that Nikita doesn't
On Mon, 15 Nov 2021 at 09:56, Hans Henrik Bergan wrote:
>
> if hosting it ourself is a priority,
No, quite the opposite.
The PHP project is pretty terrible at running infrastructure, as
infrastructure needs to have people available to work on it
immediately when there are issues, which is not a
On Tue, 2 Nov 2021 at 14:19, Nikita Popov wrote:
>
> I'd like to formally propose to use GitHub for PHP implementation issues as
> well: https://wiki.php.net/rfc/github_issues
In general, yes please. The only bit I'll chime in on is:
> bugs.php.net will remain active for the following purposes:
On Tue, 5 Oct 2021 at 18:47, Mike Schinkel wrote:
> Consider the `Type` class[3] in the `SebastianBergmann\Type` namespace. It
> contains 60 lines of function declaration to define 14 functions that all
> return `false`.
PHP allows you to define functions on one line:
function
On Mon, Oct 4, 2021 at 1:20 AM Stanislav Malyshev
> I'm not sure if anyone is maintaining it right now - but
> it'd be nice to have changes to counter that
The code for bugs.php.net has a huge amount of tech debt and is a
scary thing to touch.
On Mon, 4 Oct 2021 at 09:46, Nikita Popov wrote:
Go Kudo wrote:
> Dan Ackroyd wrote:
>> you can _simply_ include ext/random/random.h." sounds pretty
>> dismissive of causing possibly unneeded work for downstream projects.
>
> The point I was trying to make was that while BC Breaks do occur, they are
> very easy to
1 - 100 of 622 matches
Mail list logo
