On Tue, 11 Apr 2023 at 12:24, Sara Golemon wrote:
> > I'm saying that the DX for writing extensions is better in other
> languages.
>
> Citation needed. Java's extension API is certainly a hot mess. Python's
> is fine, but ultimately has similar pitfalls to PHP's. Go's looks very nice
> at
On Tue, 11 Apr 2023 at 03:00, Sara Golemon wrote:
> I'm sorry. I must be misunderstanding you. Are you implying PHP has no
> native extension mechanism/API?
>
No. I can't see that reading in what I wrote.
I'm saying that the DX for writing extensions is better in other languages.
And that
On Sun, 9 Apr 2023 at 22:52, Deleu wrote:
> But what's the point of starting a greenfield project in PHP while
> Typescript is right there?
>
An angle that isn't discussed enough is the ease of writing extensions for
other languages compared to PHP. I've written PHP for 23 years, and I'm
On Mon, 17 Oct 2022 at 09:57, Nicolas Grekas
wrote:
> I created this patch/PR to show the changes that would be required on
> Symfony to work around the BC break:
> https://github.com/symfony/symfony/pull/47882
>
> Note to readers: in this whole discussion, Symfony is just an example of
>
On Fri, 26 Aug 2022 at 09:56, Paul Crovella wrote:
> I'm for this as well. Though something more than a boolean is useful to
> indicate when the max depth has been exceeded as that's not strictly a
> problem with the json's validity.
>
That's a good point which I had overlooked. Does an
Hi Juan,
On Thu, 25 Aug 2022 at 17:02, juan carlos morales <
dev.juan.mora...@gmail.com> wrote:
> RFC: https://wiki.php.net/rfc/json_validate
Thanks for bringing forward this RFC. I am in favour of this change, as you
can't efficiently validate JSON in userland.
Like Rowan I'm not convinced
On Tue, 23 Aug 2022 at 19:09, David Gebler wrote:
> I can just see floor_div and floor_mod getting mixed up
> with fdiv and fmod but maybe I'm overthinking it, maybe it wouldn't really
> be an issue. Maybe there's alternative names you could give them though
> again I suspect the ones you've
On Sun, 22 May 2022 at 03:26, Ben Ramsey wrote:
> In my reading of the RFC, I assumed the first approach: completely
> remove the syntax and make "${}" result in the literal string "${}".
>
I voted Yes on this RFC, and that was my expectation.
Otherwise we haven't entirely removed it, and left
On Wed, 30 Mar 2022 at 15:33, Guilliam Xavier
wrote:
> Not really a "compelling reason why we should keep this inconsistency", but
> I have occasionally relied on array autovivification *for sub-dimensions*,
>
I rely on this often when remapping data for analysis. These scripts are
run a
On Wed, 16 Mar 2022 at 13:27, Rowan Tommins wrote:
> On 15/03/2022 23:02, Patrick ALLAERT wrote:
> > This is not far from the reason why I voted "no".
> >
> > I am not against the fact this warning becomes an error per se. I am just
> > not very fan of cherry-picking an individual kind of
On Thu, 25 Nov 2021 at 20:58, Dan Ackroyd wrote:
> For the people who are currently voting 'no', I'd ask are you really
> sure that the amount of work adding "#[AllowDynamicProperties]" to the
> classes you want to keep having dynamic properties is really that much
> time compared to the time
Hi list,
On Tue, 16 Nov 2021, 00:21 Deleu, wrote:
> I see a pattern in these discussions from two mindsets: one thinking about
> how we should design the future and another thinking about how we preserve
> the past.
I would frame that differently as those who
1. Predominantly write new code
On Sat, 13 Nov 2021, 00:14 Christoph M. Becker, wrote:
> Offering an
> opt-out of dynamic properties or some switch to disable the deprecation
> would not help in that regard.
>
Given this is a big change to the way PHP has behaved for decades I did
wonder why the RFC didn't propose an opt-out
On Sun, 19 Sept 2021 at 14:12, tyson andre
wrote:
> What are your thoughts on adding `ARRAY_FILTER_REINDEX`, to ignore the
> original int/string keys and replace them with `0, 1, 2, ...`
>
If it's measurably faster/more memory efficient than
array_values(array_filter(...)) across a range of
Hi Tyson,
On Sat, 18 Sept 2021 at 16:46, tyson andre
wrote:
> Many of php's names are based on the naming choices in libraries made in
> C/C++.
> So using https://cplusplus.com/reference/vector/vector/ for my RFC
> https://wiki.php.net/rfc/vector
> seems like the most natural naming choice,
>
On Sat, 18 Sept 2021 at 02:49, tyson andre
wrote:
> > To echo Pierre, a Vector needs to be of a single guaranteed type.
> > Yes, this gets us back to the generics conversation again, but I presume
> (perhaps naively?) there are ways to address this question without getting
> into full-blown
On Thu, 2 Sept 2021 at 09:27, Kevin Lyda wrote:
> The change I've made will allow people to disable the
> cache so that it won't cause errors and it leaves the current broken
> behaviour in place.
>
Is there any good reason not to remove it completely?
I've been bitten by the stat cache before
On Fri, 6 Aug 2021 at 08:18, ignace nyamagana butera
wrote:
> I read your RFC and I understand the intent in improving the current
> parse_str function behaviour by introducing a new function to
> avoid possible breakage,
> However I feel that we are missing a chance to also improve how
> > Currently there are people with voting permissions that do vote, yet do
not interact with RFCs or the mailing list.
On Mon, 19 Jul 2021 at 23:34, Bob Magic wrote:
> i'd say we need something more modern and transparent than this old mailing
> list, but i completely lack a suggestion that
On Mon, 28 Jun 2021 at 17:08, Larry Garfield wrote:
> Javascript doesn't have it natively, but there are 3rd party libraries
> that try to do it.
>
There is a proposal to add it to the language:
https://github.com/tc39/proposal-partial-application
Peter
On Wed, 16 Jun 2021 at 17:17, Larry Garfield wrote:
> Hi folks. The vote for the Partial Function Application RFC is now open,
> and will run until 30 June.
>
> https://wiki.php.net/rfc/partial_function_application
>
I like. People have either experienced the need for this or they haven't.
Ask
On Wed, 9 Jun 2021 at 15:55, Levi Morrison via internals <
internals@lists.php.net> wrote:
> On Wed, Jun 9, 2021 at 8:12 AM tyson andre
> wrote:
> >
> > Hi Levi Morrison,
> >
> > > > > Hi internals,
> > > > >
>
Would participants please trim the emails they're quoting, it makes it
easier for
On Mon, 10 May 2021 at 22:52, Kamil Tekiela wrote:
> Almost all new contributors fall into this trap and reply to a thread by
> top-posting, only to get chastised by someone else on the list.
>
I like bottom-posting or point-by-point replies, but would drop the rule
and make the list a more
On Sat, 3 Apr 2021 at 17:30, Benjamin Eberlei wrote:
> The problem is that "void" is already not perfect, since the callside
> doesn't care about "return null" with no return type vs "return" + void
> return type.
>
> If we had "nothing" and "null" instead of "void", and we'd say like PHP
>
On Thu, 11 Feb 2021 at 13:31, Christian Schneider
wrote:
> For the record: I do not think the wording fo the "Backward Incompatible
> Changes" section is appropriate, especially the *only* in "To bring back
> the old behaviour one needs to add only this line before instantiating
> mysqli class".
On Mon, 1 Feb 2021 at 15:40, Bob Weinand wrote:
> My main concern in this iteration of the RFC is: what happens with
> big/deeply nested objects?
> They tend to spew tons of lines if var_dump()'ed. Do we have reasonable
> depth/output limitations in default dumping mode?
>
Good catch Bob, I'd
On Mon, 4 Jan 2021 at 15:21, Pierre R. wrote:
> I do not agree with having values per default, this is error prone in
> most of my use cases.
>
> In most case where I need enums, I often need to replicate those in
> database too, or in message broker serialized messages: in this context,
>
On Fri, 18 Dec 2020 at 16:43, Máté Kocsis wrote:
> Also, please
> be aware that the timeout is a clean shutdown
> mechanism, so shutdown handlers and the already
> mentioned RSHUTDOWN functions are triggered. On the other hand, fpm's
> timeout doesn't invoke any of them.
>
Tangentially, can
On Wed, 14 Oct 2020 at 00:56, tyson andre wrote:
> There's two main options available for testing out php in a browser right
> now:
>
> - A general sandboxed php implementation hosted by the owners of php.net
> (requires that it be secured and may lead to additional hosting costs),
>
On Tue, 1 Sep 2020 at 08:59, Marco Pivetta wrote:
> Did the namespaces ship sail forever? Can we just have those instead,
> please?
>
To mix metaphors: it sailed, shot down in fiery flames.
Unfortunately.
Peter
On Wed, 19 Aug 2020 at 09:46, Jordi Boggiano wrote:
> Just to mention something here in a bit more depth because it is easy to
> overlook in the RFC if you have looked at it a lot.
>
> In "Potential Future Benefits of Enclosed Delimiter Syntax" there is an
> addition of an example using an
On Sun, 16 Aug 2020 at 10:29, Benjamin Eberlei wrote:
> We have updated the RFC at
> https://wiki.php.net/rfc/shorter_attribute_syntax_change with what we
> think
> covers all the discussion and arguments made in this and the previous
> mailing list threads.
>
Thank you for putting in the work
(Resending, as my @php.net email address never makes it to the list)
On Sun, 16 Aug 2020 at 07:42, Jakob Givoni wrote:
> Can I make a suggestion?
>
> Make the new or updated RFC a primary vote on: "Should attributes be
> enclosed in delimiters?"
> This is what we're really discussing and that
On Mon, 17 Aug 2020 at 02:06, Theodore Brown wrote:
> ## Forcing @@ attributes to end with parenthesis?
>
> I don't really see the point of this section in the RFC.
The blame for that is on me, not Benjamin and Derek, as I repeatedly asked
why a compulsory ) could not be considered a closing
On Sat, 15 Aug 2020 at 16:07, tyson andre wrote:
> I also want a revote.
>
I do too.
Partly because of the rules, but mostly because this discussion has gone on
so long I am now less clear about what is an "ending delimiter" and why it
matters than before.
And whether the begin/end delimiters
On Mon, 10 Aug 2020 at 15:41, Peter Bowyer
wrote:
>
>
> On Mon, 10 Aug 2020 at 14:59, Derick Rethans wrote:
>
>> I did answer that as a reply to Rowan:
>>
>> https://externals.io/message/111312#111346
>
>
> I'm with Rowan's response to you:
> https://e
On Mon, 10 Aug 2020 at 14:59, Derick Rethans wrote:
> I did answer that as a reply to Rowan:
>
> https://externals.io/message/111312#111346
I'm with Rowan's response to you: https://externals.io/message/111312#111354
What is the difference between mandatory parentheses giving:
<><>(
On Mon, 10 Aug 2020 at 10:15, Rowan Tommins wrote:
> I am not a fan of the @@ syntax, and respect what you're trying to do with
> this RFC, but am disappointed you haven't engaged with those of us who said
> that the RFC needs more detail. There is simply not enough information in
> that table
On Thu, 6 Aug 2020 at 08:18, Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
> As said before, it does have an ending delimiter when they are arguments
> since
> there is the parenthesis around them. When there are no arguments I don’t
> see
> the benefit of an ending delimiter, it’s
On Tue, 4 Aug 2020 at 08:39, Gabriel Caruso wrote:
> The branch will happen around
>
> - 1 am (+1 day) UTC+8 (SGT)
> - 7 pm UTC+2 (CEST, my timezone)
> - 6 pm UTC+1 (BST)
> - 1 pm UTC-4 (EDT)
>
> Let us know if you have any questions!
>
Will it be livestreamed? /jk
Seriously, it's a great time
On Mon, 3 Aug 2020 at 19:52, Stanislav Malyshev wrote:
> I think turning JIT off is a valid use case, the rest looks much more
> iffy. I am not sure we want to let people tell the engine to JIT certain
> functions - are there a lot of cases where the engine wouldn't do it but
> it's actually the
As a general point, Python went through this almost 2 years ago. Their PEP
is worth reading (I didn't see it mentioned before):
https://www.python.org/dev/peps/pep-0570/
Peter
On Fri, 24 Jul 2020 at 12:13, Chris Riley wrote:
> Hi all,
>
> The named parameters RFC has been accepted, despite
On Thu, 16 Jul 2020 at 09:04, Nikita Popov wrote:
> While I don't think anyone had plans to mix whitespace, this is indicative
> of a larger issue. While I'm one of the people who voted for @@ as my first
> choice before, I wouldn't do so now (even with this RFC accepted). This
> issue made me
On Thu, 9 Jul 2020 at 14:52, Benjamin Eberlei wrote:
> For me the RFC vote should be "allow to dcelare return types on
> constructors/destructors?", then people *can* declare void, but *can* also
> declare other things, but nothing *must* be done. Then it becomes a
> question of coding styles
On Tue, 7 Jul 2020 at 15:47, Larry Garfield wrote:
> This has reached the 2 week mark, but there's not been much discussion.
> Anyone else want to weigh in?
>
Looks good; nothing more to say.
Peter
Hi,
I have voted in favour, but enough people I respect have voted against to
make me reconsider.
My understanding is the changes will only cause problems to people who have
returned something from __construct() or __destruct(). As people shouldn't
have done this, IMO it is a smaller BC issue
On Tue, 16 Jun 2020 at 11:41, Dan Ackroyd wrote:
> Note, I haven't done the work to actually make sure that this plan is
> actually feasible, so it's not guaranteed to be the correct approach.
> But it still sounds sensible and would scale out to other custom
> methods for other connection
Hi list,
4 months ago there was a discussion about the future of SQLite3 and
PDO/SQLite extensions (https://externals.io/message/108256), highlighting
the effort required to maintain two codebases.
Recently I encountered https://bugs.php.net/bug.php?id=64810 and thence
On Mon, 15 Jun 2020 at 20:07, Thomas Nunninger
wrote:
> Before discussing technical aspects about what changes would be required
> and what are the consequences, I'd like to point out some other aspect:
>
> I'm a white guy. I can't tell women how they should feel about male
> wordings,
Hi Theodore,
On Thu, 4 Jun 2020 at 00:55, Theodore Brown wrote:
> https://wiki.php.net/rfc/shorter_attribute_syntax
Thanks for creating this RFC and for including "Comparison to other
languages" in it. A provisional +1 from me.
Does the PHP parser prevent us from adopting #[attr]? I presume
On Fri, 22 May 2020 at 12:09, Nikita Popov wrote:
> While I'm happy with "Attribute" living in the global
> namespace, I don't really think we'd want to introduce "Jit" as a class in
> the global namespace. The name is simply to generic and does not indicate
> that this is part of the attribute
On Tue, 5 May 2020 at 07:38, Niklas Keller wrote:
> Rowan Tommins schrieb am Mo., 4. Mai 2020,
> 10:59:
> > Although the name sounds similar, I don't think UUID would be a good
> > replacement for uniqid(). In my experience, it's used for things like
> > generating ID attributes for HTML
On Tue, 21 Apr 2020 at 12:35, Benjamin Eberlei wrote:
> The discussion on this RFC was 5 weeks and the syntax suggestions until
> yesterday have all been suboptimal.
>
I appreciate the discussion period was 5 weeks, which was a generous
allowance. It's also been an unusual 5+ weeks, with life
On Tue, 21 Apr 2020 at 09:15, Peter Cowburn wrote:
> I know that I'm "too late" to be making suggestions, but I would like to
> see
> a new "@@" operator over the proposed <<...>> or @:.
>
I support this, and agree with Theodore Brown's earlier message (
>
> For details, see the full writeup:
>
> https://hive.blog/php/@crell/improving-php-s-object-ergonomics
An excellent writeup, thank you Larry.
Peter
On Fri, 28 Feb 2020 at 15:25, Paul M. Jones wrote:
> Are there any members here who currently expect to vote "no", who have not
> yet chimed in? I'd like to hear your criticisms and objections, so I can at
> least attempt to resolve your concerns.
>
I expect to vote "no". My thoughts are:
1.
On Fri, 14 Feb 2020 at 09:18, Philipp Tanlak
wrote:
> I would like to propose the new basic function: str_contains.
>
> The proposed signature for this function follows the conventions of other
> signatures of string functions and should look like this:
>
> str_contains(string $haystack,
On Tue, 11 Feb 2020 at 09:34, AllenJB wrote:
> If you want to change the way developers think about hashing when
> writing PHP, I would start with the documentation rather than
> deprecating functions which are essentially aliases and are highly
> likely used all over the place in cases where
On Tue, 28 Jan 2020 at 17:12, Rowan Tommins wrote:
> I'd just like to point out that those two things are orthogonal: the fact
> that Swoole is distributed as an extension is not the reason it's
> incompatible with your existing code, and building a similar implementation
> into PHP under a
On Tue, 28 Jan 2020 at 14:26, Thomas Hruska wrote:
> People tend to write WebSocket servers in NodeJS partly because they
> don't realize that PHP can already do the same. Example:
>
> https://github.com/cubiclesoft/php-drc
I didn't realize, so this is a great share. Thanks.
> WebSocket
GMail fails to parse the URL correctly, so for users the link is:
https://wiki.php.net/rfc/class_name_literal_on_object
Peter
On Tue, 28 Jan 2020 at 09:15, Nikita Popov wrote:
> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/class_name_literal_on_object.Voting closes
>
On Sun, 17 Nov 2019 at 23:44, Ben Ramsey wrote:
>
> > On Nov 17, 2019, at 17:28, Mike Schinkel wrote:
> >
> > If we are going to open up arrays for enhancement in PHP 8 I would ask
> that we seriously consider addressing the various differences between a
> built-in array and an instance of
On Fri, 25 Oct 2019 at 00:28, Sara Golemon wrote:
> At the risk of hijacking, @matthewrask asked me about ?-> a couple weeks
> ago (Javascript is making this one popular), and I threw together a rough
> PoC at
> https://github.com/php/php-src/compare/master...sgolemon:null-coalesce
> which
> I
On Thu, 24 Oct 2019 at 13:47, Rowan Tommins wrote:
> I think this performance impact is a real concern; PHP is the only language
> I know of which implements type checks entirely at run-time in production
> code, and we should ask ourselves if that's definitely the right approach.
>
As they are
On Sun, 15 Sep 2019 at 14:16, Zeev Suraski wrote:
> > How can an undefined group have copyright vested in it?
>
> It's very much well-defined. And certainly not by Wikipedia, but in the
> PHP source code and the php.net website itself. Right at the top of the
> Credit page:
>
Hi Benjamin,
I like the proposal.
On Mon, 16 Sep 2019 at 01:40, Benjamin Eberlei wrote:
> I am asking about feedback especially on the section "Implementation
> Details", that explains some key differences to "PHPify" the DOM Living
> Standard API to PHP and ext/dom. Do you have any comments
On Sun, 15 Sep 2019 at 06:48, Joe Watkins wrote:
> The Wikipedia states that PHP is developed by the PHP Group, in saying this
> it is (must be) referring to internals as a whole, but our own
> documentation names members of the group - who aren't even around mostly.
>
> I think we need to
On Thu, 12 Sep 2019 at 19:10, Lynn wrote:
> Whenever one of these errors will occur, you can initialize either the
> array key or variable with null and it will work again without changing
> behavior. If anything, Wordpress shouldn't be an argument to not improve
> PHP, though I think it's
On Wed, 4 Sep 2019 at 12:30, Arnold Daniels
wrote:
> Instead of using `__toString` as type maybe it's better to introduce a
> `Stringable` interface, similar to how `__wakeup` and `__sleep` are already
> superseded by `Serializable`.
I support that. I don't like the naming in
On Thu, 29 Aug 2019 at 08:28, Christian Schneider
wrote:
> Side-note: Which brings us back to the discussion about the downsides of
> language modes but as similar topics keep on popping up (although by the
> same people) you are slowly convincing me that going down that road is the
> best
On Tue, 20 Aug 2019 at 17:18, Peter Kokot wrote:
> Let's simplify this a bit because I'm not sure I have seen anyone
> mentioning something like a PHP 10 milestone in all these discussions.
> If we want to get rid of some feature like this a very long timeline
> needs to be done and also major
Hi Stas,
Thanks for replying!
On Sun, 11 Aug 2019 at 04:26, Stanislav Malyshev
wrote:
> The risk here however is for the document to be seen as a means to
> "argue less" by way of excluding certain points of view from discussion.
> That would not be a good thing. This is the main concern for
On Sun, 11 Aug 2019 at 05:32, Andi Gutmans wrote:
> I must admit that the first time I read Zeev’s email I got anxious... but
> it is frustrating that PHP has a WAY better runtime than Python and most
> other dynamic languages yet is falling out of fashion.
In the case of Python, it seems to
[List etiquette question: is it good form here to change the subject line
when starting a tangential discussion?]
On Sat, 10 Aug 2019 at 00:08, Larry Garfield wrote:
> PHP doesn't have a coherent philosophy. It is proudly directionless,
> steered by whoever happens to be writing code this
On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd wrote:
> I think when we adopt a Code of Conduct one of the things we need to
> make explicit is that "claiming authority that is not codified" is
> explicitly a thing that will not be allowed in internals discussions
> as it seems to keep happening and
On Tue, 23 Jul 2019 at 21:56, Nikita Popov wrote:
> I did not want to just merge the original (accepted!) implementation after
> the controversial discussion it triggered, but after reading this, I
> realize that I just wasted my time here. So much for being nice and giving
> people a fair
On Mon, 8 Jul 2019 at 19:09, Björn Larsson
wrote:
> Having this _ci postfix is a new way of indicating case insensitivity.
> I think that it might add to negative votes. Personally I think it's a
> good idea to mimic existing ways, even if they are a bit awkward.
>
> How about using a flag or
Hi Andrey,
Thanks for taking the time to push forward this RFC.
I found the earlier discussion at https://externals.io/message/104744,
which I hadn't seen. Like others, I would have chosen to keep {} for string
offsets to make it clearer, though I have not used {} in my code for a
decade. Was
If the problem is that (multiple) people find the page too long to scroll
through, we can add some JavaScript to the output to hide the stats by
default.
This could be a good time to make all blocks on the page collapsible, with
a "Collapse/Expand all" link added at the top.
All added as
On Tue, 7 May 2019 at 20:05, Stanislav Malyshev wrote:
> So before just swinging the ax and dropping it I think we should really
> research what people are actually using open_basedir for. And then try
> to formulate a proper description of what it can be used for without
> claiming any security
On Mon, 25 Mar 2019 at 19:28, Ben Ramsey wrote:
> If someone enters nonsense or “n/a” or any value that doesn’t justify
> their vote or doesn’t appear to satisfactorily justify it according to some
> metric of justification satisfaction, then does that person’s vote get
> thrown out or
On Mon, 25 Mar 2019 at 15:24, Andreas Heigl wrote:
> Shall we then also expect people that vote "yes" to explain why they voted
> for the feature? To see whether they understood what they where voting on?
>
Yes.
> Then we should couple the vote to a comment in the wikinpage and without a
>
On Mon, 25 Mar 2019 at 14:02, Dan Ackroyd wrote:
> I don't believe forcing people to explain their votes actually does that.
>
> It does something quite similar, of forcing people to try to
> articulate how the RFC needs to change for them to change their vote
> from a no to a yes. At least that
83 matches
Mail list logo
