Re: [PHP-DEV] Future stability of PHP?

[Peter Bowyer]

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 first blush, but given that it's closer to an FFI than a proper
> extension API, shortfalls inevitably show up when you try to do anything
> complex.
>

Python's the one I had in mind. Also Node. I've read but not written node
extensions and found them very readable. Even when using Native
Abstractions for Node.js (nan) which adds a macro layer.

With compiled languages I'd think of Nim, Crystal and Swift but have no
practical experience with any of them, only having read the source of a few
extensions and run through the tutorials to write them.


> > And that these days new products come along and provide extensions for
> > other languages but not PHP. Which is a problem I can only work around by
> > writing an extension.
>
> Okay. Why is this a problem?  This is what's right about OSS.  That you
> can take two things and smush 'em together because you need something from
> both.
>

I see this as a problem for PHP users and for PHP adoption.

Lack of PHP support from vendors is a strategic problem for future
ecosystem health. There will be multiple reasons¹ vendors will choose to
support other languages and not PHP, but one certainty is it means funded
startups are not putting their cash towards PHP.

For users of PHP, when we look at using a 3rd party service, I would
imagine most of us don't price in the cost of building, maintaining and
supporting our own extension. The outcome would be to not use the service -
or to change language to one where there isn't this friction. Needing to
write an extension to be able to build your app on top makes the platform
behind before the race is even started.

¹ I am interested to find out what their reasons are. Why don't companies
choose to make PHP extensions? Is it that PHP is inconsequential to them,
the perception that PHP users are too small an audience, difficulty of
creating the extension, or other reasons? They aren't going to answer me as
a random person, but if the PHP Foundation want some market research done
then this is your opportunity.


> > PHP now has FFI which provides an easier way to extend PHP. I have huge
> > hopes for it - but in my experience it doesn't feel finished.
>
> I agree, it's not finished.  But the problem there is also the
> opportunity.  OSS works best when people who have an actual need are the
> ones designing the interfaces and making things better.
>
> I don't pay attention to FFI because I can write PHP extensions on a my
> mobile, while sitting on an island beach and playing board games (true
> story).  I know that's not universally true, but it's why I'm not putting
> the effort in, because I'll end up building the wrong solution by not truly
> understanding the requirements (also a true story, take a look at streams
> sometime).
>
> If it feels like FFI is stalled, it's probably because it's "good enough"
> for the people who got it to this point.  The itch is scratched and the
> need is met.
>
> So when I call the state of FFI an opportunity, I'm not saying "code or
> gtfo" as such is sometime vilified.  I'm saying this is an open source
> project of the purest kind and it really is up to someone to care about a
> thing enough to put in the work to make it better.
>
> And if your reply is, "But I don't know C", then good news! That's another
> opportunity.  PHP is a nice language, but it's not the only one out there.
> C is a mother language, the payoff on learning just keeps coming around.
>

>From the times I have tried (the last one on this list being around PDO and
driver-specific functions) C is not an insurmountable problem, but
understanding the PHP/Zend macros was, even after going through the PHP
Internals book. It looks like the book has been updated since last time
though, which will help.

More recently I have been playing with a DuckDB library using FFI and then
working through the code at
https://github.com/kambo-1st/ipc-duckdb-ffi-extension-workshop /
presentation
https://docs.google.com/presentation/d/1_hGrKsJey9YvFMGrKk34p_hRmfPU4swiaUhCpVygVjo/edit.
That might be manageable to complete.

I won't be stepping up to work on FFI because IMO that requires more
experience than I can bring - in extension writing, and particularly in
using FFI and knowing its strengths and pitfalls inside-out. For keeping
track of what I and others find while using FFI, is this mailing list or a
GitHub issue the best place to record it?

Peter

Re: [PHP-DEV] Future stability of PHP?

[Peter Bowyer]

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 these days new products come along and provide extensions for
other languages but not PHP. Which is a problem I can only work around by
writing an extension. Or convincing them to write an extension.

PHP now has FFI which provides an easier way to extend PHP. I have huge
hopes for it - but in my experience it doesn't feel finished. php-vips is
the biggest example of using it that I've seen.

Peter

Re: [PHP-DEV] Future stability of PHP?

[Peter Bowyer]

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
increasingly looking to other languages because they either come with a
prewritten extension PHP doesn't have or because I can more easily hack one
together to wrap a library (example: a new DB client)

PHP has FFI but IMO it would benefit from further development. And the
benefits of native extensions will often be what's needed instead of FFI.

Peter

Re: [PHP-DEV] [VOTE] Improve unserialize() error handling

[Peter Bowyer]

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
> affected code. In the end, Symfony will adapt to the RFC if it passes. The
> point being made is that PHP scripts should not have to be patched to run
> on newer minor versions of PHP. That's what "keeping BC" means.
>

 I didn't think there was much reason for the negative fuss being made
around this PR, after all catching \Throwable or another exception doesn't
make much difference. Seeing the workarounds here however it is more
involved than I expected.

I have changed my vote for the first point to "No". I’d like to see this
implemented in future (9.0?) but now agree that 8.3 isn’t the right place.

Peter

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Peter Bowyer]

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 exception make most
sense when this happens?

Peter

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Peter Bowyer]

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 JSON_THROW_ON_ERROR belongs here. I can't
think of a case where more than a boolean response is needed.

Peter

Re: [PHP-DEV] Proposal for floored division and modulo functions

[Peter Bowyer]

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 chosen are the most obviously sensible to
> describe what they do.
>

 Is this not one time where using a flag to change a function's behaviour
makes sense? So rather than fdiv, floor_div, int_div (etc) we have div($1,
$2, DIV_FLOAT), div($1, $2, DIV_FLOOR), div($1, $2, DIV_INT).

I'm not proposing div (non namespaced) as the name as I expect it clashes
with a lot of UDF's, but it works well in this example.

Re: [PHP-DEV] Re: Removal of ${} string interpolation in PHP 9

[Peter Bowyer]

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 a footgun for people
with a new special case that isn't variable interpolation and isn't normal
characters in a string.

Peter

Re: [PHP-DEV] Undefined variables and the array append operator

[Peter Bowyer]

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 handful of times and discarded. Autovivication keeps the code short.
Here's a snippet I wrote yesterday:

$out = [];
while ($row = $res->fetchAssociative()) {
// ...
$docId = $row['document_id'];
if (!isset($out[$docId])) {
$out[$docId] = [
'application_id' => $row['application_id'],
'document_id' => $docId,
'filename' => $row['filename'],
];
}
$out[$docId]['labels'][$row['document_rejection_reason_id']] =
true;
}

Naturally I would prefer to keep this behaviour for arrays.

Peter

Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion

[Peter Bowyer]

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 problem (read:
> > notice/warning/error/...) and changing it without a more global frame.
>
>
> I have also voted no for similar reasons: the scope of this RFC appears
> to be "all the places that are convenient", rather than "all the places
> that are covered by the claimed rationale".
>
> [snip]
>
> None of this is even mentioned in the RFC, let alone justified.
>

I have voted no for the same reasons.

Peter

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

[Peter Bowyer]

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 that would be saved by having PHP itself
> give an error when a user accidentally creates a dynamic property?
>

No, I don't. I see the vote as a "boiling frog" moment and a protest vote
in reaction to other changes which have had a bigger impact on
backwards-compatibility.

---
I get the impression a lot of comments on this mailing list are from people
who know other languages, would like to work with another language, and
since they (have to?) use PHP would like PHP to be another language.

I find that fascinating. And I'd be well up for having a round-table
discussion and recording a podcast on it.
---

PHP fills a big niche. it's not the niche that most people on this list
seem to want it to fill, but it does. And the results people accomplish
with PHP - not in spite of PHP, but because of PHP - are impressive.

There are unresolved discussions that have been going on since at least
2019 [1] about direction and what PHP should become. With the formation of
the PHP Foundation I hope these can be revisited.

Peter

References:
1. https://externals.io/message/106453

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

[Peter Bowyer]

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 (most of us on this list I expect)
2. Use ecosystems written in PHP (talking from personal experience I have
WordPress and Drupal in mind, but I see it with Laravel and to a smaller
extent Symfony users too).

Both approaches are massive audiences for PHP and both have different
needs.

For the second group, finding that something you built on no longer works
because "PHP changed" is a problem, in a way it isn't for members of this
list, who would likely fork and fix it. It's easy to use the glib response
that "it's open source, they should get their hands dirty" but for many,
knowing how to get started is a barrier that stops them. Making a big
generalisation, this audience is hugely proud of what they do manage to
accomplish and can be hugely vocal proponents for PHP (ecosystems).

Yet it's not always lack of knowledge either that makes small
backwards-incompatible changes a problem. If you're a small business your
focus is elsewhere and what those working at larger and highly profitable
or well funded companies see as a small expense (however annoying) is a big
loss of other opportunities that a small business could use to grow. I see
this with some clients, where a day is a big deal, and a day spent testing
an upgrade is a day not spent fixing the problem 5% of customers have.

I take it as read that we want to continue serving both audiences.

On improving PHP, there is a prevalent view on this list that the
competition is people going to other programming languages. The hidden
competition is people saying "keeping up isn't worth the effort" and
switching to centralised SaaS offerings. We see all the good reasons for
doing this playing out in our own "Switch to GitHub Issues" discussion.
It's happening enough, we don't need to encourage it.

Returning to this RFC it may surprise people that I like the idea of only
having dynamic properties on stdClass & children. I don't go as far as
saying "this is how it should have been from the start" as the culture was
different when classes were introduced to PHP. But dynamic properties have
been around since the start and I am wary of deciding to remove them in PHP
9.

Kind regards,
Peter

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

[Peter Bowyer]

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 of dynamic properties rather
than opt-in, preserving the long-term language behaviour. So thanks for
covering that.

I think you and the PHP internals community will be surprised by how widely
used dynamic properties are. I read through a handful of WordPress plugins
we have installed and found a few. And in my own where I'm using a named
class instead of an array.

I work with modern framework based code most of the time and I find it easy
to forget what is out there as quintessential or traditional PHP code.

Whether we have #[AllowDynamicProperties] or #[DenyDynamicProperties] one
set of PHP users is going to be doing a find & replace across their
codebase.

>From a DX perspective I'd rather have #[DenyDynamicProperties] as it's like
declaring strict_mode and opt-in.

Either way are the planned engine changes feasible, as the feature of
dynamic properties stays in the language but toggled off/on per class?

Peter

>

Re: [PHP-DEV] Proposal: Adding an ARRAY_FILTER_REINDEX flag to array_values

[Peter Bowyer]

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 array sizes, I'm strongly
in favour as I write this a lot.

Peter

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Peter Bowyer]

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,
> and would make it easier for people with backgrounds in that family of
> languages to find the functionality they're looking for.
> PHP already has a SplStack, SplQueue, etc, like C++'s `stack`, `queue`,
> etc.
>

That is a fair point. Vector is an overloaded and common word. For me a
vector will always default to an entity characterized by a magnitude and a
direction, because that's what I learned and used for years. The next
definition I learned was the Numpy one.

That for me is the sticking point if this Vector allows mixed types which
include arrays or vectors. Store them inside a Vector and then you end up
with a matrix, a tensor and so-on in something identified as a Vector,
which is nonsense. Yes C++ does that [1]. Yes with generics it sort-of
makes sense. Numpy gets round it by calling the type `ndarray` and a vector
is a specialised one-dimensional array.

If it's a high-performance array and that's the goal, call it hparray. Call
it a tuple. Call it a dictionary.


> Also, your comment is ambiguous. Are you saying that you personally object
> to the name,
> or that you're fine with the name but think that the comments by
> Larry/Chris/Pierre in this email thread are representative of voters.
>

Both.

I object to the name for what's being proposed, but am not necessarily
against what's being proposed if it looks more useful than the Spl* stuff.

I'm fine with the name but for something other than what's being proposed.

HTH
Peter

1. https://www.geeksforgeeks.org/vector-of-vectors-in-c-stl-with-examples/

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Peter Bowyer]

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 generics.
>
> Yep, as you said, this type is mixed, just like the SplFixedArray,
> ArrayObject, values of SplObjectStorage/WeakMap, etc.
>

Please rename your proposal as the use of the term "Vector" is confusing
for people who use them in other languages. Much of the discussion so far
has been around whether it's a Vector or what it should be; changing the
proposed name will allow the discussion to focus on what you're proposing
to add, not what others (myself included) would like to see added to PHP :)

Peter

Re: [PHP-DEV] Adding a way to disable the stat cache

[Peter Bowyer]

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 and would be pleased to see it
gone for good.

Peter

Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str

[Peter Bowyer]

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 parse_str
> algorithm is currently used, we could or should (?) use this opportunity
> to fix some long shortcomings around parse_str.
>
> In no particular order:
>

I agree that the first 2 shortcomings ought to be addressed in a
HTTP-focused parse_str alternative. The first has been an annoyance, as
some querystrings use '.' to denote an array, in the way PHP chooses []. So
foo.bar would mean foo[bar] in PHP-speak.

The third I won't comment on as I don't know the Url algorithm.

Peter

[PHP-DEV] Problems with the mailing list [was: Re: [PHP-DEV] Request for karma to vote on RFCs]

[Peter Bowyer]

> > 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 isn't somehow worse than what
> we got now in terms of massively multiplayer discussion.
>

I have now been contacted by 2 people who tried multiple times to join this
mailing list and cannot.

It took me 5 weeks for my signup to work. During that time I emailed the
different @php.net mailboxes related to infrastructure and/or the web and
received no response. Eventually I managed to sign up - once I created this
brand-new Gmail account. The signup form is unreliable.

There are people wanting to take part in discussions who can't.

I volunteer to help sort this. Can someone who knows the PHP group
procedures please tell me the next steps?

Peter

Re: [PHP-DEV] [Vote] Partial Function Application

[Peter Bowyer]

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

Re: [PHP-DEV] [Vote] Partial Function Application

[Peter Bowyer]

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 me a month ago and I would have said "pfft, waste of time and language
bloat" but I changed my mind recently after running into issues in
JavaScript and discovering I needed partial function application to fix it
cleanly (vs a mess of mixed function calls and closure-wrapped function
calls).

I am a little ambivalent as I do feel the RFC's complexity has grown - I
would be happy without the variadic placeholder being included if it's a
choice between no partial function application or placeholders only. But if
I don't want to use variadic placeholders, hey I can omit them from my code.

Peter

Re: [PHP-DEV] Re: RFC: CachedIterable (rewindable, allows any key keys)

[Peter Bowyer]

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 readers to focus on what's being discussed in emails.

Thanks,
Peter

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

[Peter Bowyer]

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 welcoming place for newcomers.

I doubt "bottom posting" is a term people who started online in the last 10
years know - with today/yesterday's example, my takeaway was the original
poster didn't know what it meant. There's also English familiarity to
account for.

Peter

Re: [PHP-DEV] [VOTE] noreturn type

[Peter Bowyer]

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
> works, "return;" actually means "return null;", then:
>
> function foo(): nothing {
> return; // Error: cannot return null from a function that returns
> nothing.
> }
> function bar(): null {
> return;
> // or return null;
> }
>
> This would more consistently tie into union types where |null is allowed,
> however on its own it is not: "foo() : null => error".
>
> As Levi said, this noreturn/never just perpetuates/amplifies the existing
> void mistake and feels off, given that other recent changes to PHP have
> been more bold, towards removing inconsistencies.
>

This and Levi's email make compelling arguments and I would like to see
this adopted. I have changed my vote to "No".

Peter

Re: [PHP-DEV] [VOTE]: Change Default mysqli Error Mode

[Peter Bowyer]

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". This IMHO downplays the impact for people hosting legacy
> code.
>
> Also: If there would have been an intermediate PHP version with default
> MYSQLI_REPORT_ERROR I would have voted "Yes", but in the current form I
> have to say "No".
>

I voted "No" for the same reasons.

Peter

Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`

[Peter Bowyer]

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 completely overlooked this was missing in the RFC.

I like how IPython's REPL has configuration options for this. When I start
it I can pass in arguments to truncate the output a lot or not at all. If I
always want these settings, I add them to a config file.

I hoped existing REPLs (in different languages) would have consensus about
when and where to truncate output, and representations to use; but when I
played with a few over the weekend, there wasn't. Some assume you want
everything output; others (for data structures) the first N items, and
others the first N/2 and the last N/2. Objects often show very little
that's useful.

Do you know of any research or writeups as to what works best - or even
saved output of how various REPLs show their output?

Peter

Re: [PHP-DEV] [RFC] Enumerations, Round 2

[Peter Bowyer]

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,
> whenever I need to fix a typo in a enum case name, for example, if I use
> default values, I would have errors with my existing database records or
> live messages.
>
> I prefer to keep an explicit switch/match to hydrate values from
> database or elsewhere, and use a value-less enum on the PHP side. Case
> names are the only semantically important value for the developer, and
> your code should not care about having a string value. In most cases
> only exchanges with the outside world in an heterogeneous environment
> (having a database makes it heterogeneous) care about having string
> values. In this case, I highly prefer having explicitely written
> (de)hydration code than automatic magic values happening over the place.
>

I agree.

Peter

Re: [PHP-DEV] [RFC] [Discussion] Measuring maximum execution time based on wall-time

[Peter Bowyer]

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 this be considered a bug in FPM's handling? I appreciate
the speed boost FPM brought over CGI, but the more I work with it the less
I like the way it functions (but that is a separate conversation).

Peter

Re: [PHP-DEV] PHP 8 release announcement page on php.net

[Peter Bowyer]

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),
>   https://3v4l.org/ (not open source https://3v4l.org/about - but similar
> to what I was thinking of)
>   or https://psalm.dev/ (open source) are projects in that area
>   (Matthew Brown is one of the authors of Psalm)
> - A WebAssembly solution, e.g. https://phan.github.io/demo/ (forked from
> https://oraoto.github.io/pib/)
>   (I'm one of the maintainers of Phan)
>

Add repl.it to the list: a couple of releases behind, but works very well
in my experience for testing.
https://repl.it/languages/php_cli

On the page: a big +1 from me. PHP needs some marketing, and I would like
the content to address the objections from naysayers online who start by
saying "I haven't used PHP since PHP 4/5 and I wouldn't use it because..."

Can any firms that support PHP donate a copywriter or marketing executive
to help?

Peter

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

[Peter Bowyer]

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

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Peter Bowyer]

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 attribute for an AOP-style
> before-function callback:
>
>  @:Before(fn ($x) => $x*4)
>
> IMO this is much more readable and self-documenting than a dangling
> lambda like @[fn ($x) => %x*4], as the attribute name hints at what is
> going on, and it provides enclosure with the arg list ().
>

I read a lot of code I didn't write, and I like your example.  It is much
more readable and self-documenting.

Peter

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

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 it took to revise the RFC. It's good. I
now understand what the delimiters achieve.

While I don't agree with the first point in "Forcing @@ Attributes to end
with parenthesis does not solve issues" (in this new syntax I'd ban
whitespace) I appreciate the point you are making, and it is sensible for
consistency.

I feel grep'ability has been played down, as unless
@@
MyProject\FooAttr

is allowed (which isn't shown in the codeblock), then it's easier to grep
for @@.+?Foo and know you have a chance of an accurate match (assuming
renaming is not used) than it is with the delimiter syntax.


> Sorry to everyone for causing this hazzle.
>

These things happen. Thank you for taking on-board the feedback and working
on the RFC.

Peter

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

(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 would make the intention
> and everything that follows much clearer.
>

Having read the updated (and now very good) RFC, I second this suggestion.

It feels like we've spent 2 weeks talking at cross purposes, when a
clear wording of attribute syntax vs attribute delimiter syntax would have
short-circuited much of this discussion.


> Then the secondary votes can be on the preferred block syntax.
> Voting no means to keep @@ (unless there's another RFC for voting to
> change that for another syntax without ending delimiter).
>

+1.

Peter

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Peter Bowyer]

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 delimiter.


> ## Attribute nesting
>
> The RFC points out that all the syntaxes can allow attribute nesting,
> which is true. However, it would be nice to include an example of
> potential future nesting for each syntax, as was included in the
> original Shorter Attribute Syntax RFC. The reason is that some of the
> syntaxes are less readable than others when nested (particularly `<<>>`,
> though arguably `#[]` and `@[]` as well since the attribute end
> delimiter can be confused with the end bracket of an array argument.
>
> @@JoinTable(
> "User_Group",
> @@JoinColumn("User_id", "id"),
> @@JoinColumn("Group_id", "id"),
> )
> private $groups;
>
> #[JoinTable(
> "User_Group",
> #[JoinColumn("User_id", "id")],
> #[JoinColumn("Group_id", "id")],
> )]
> private $groups;
>
> @[JoinTable(
> "User_Group",
> @[JoinColumn("User_id", "id")],
> @[JoinColumn("Group_id", "id")],
> )]
> private $groups;
>
> < "User_Group",
> <>,
> <>,
> )>>
> private $groups;
>
> @:JoinTable(
> "User_Group",
> @:JoinColumn("User_id", "id"),
> @:JoinColumn("Group_id", "id"),
> )
> private $groups;
>

Good catch.

Peter

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

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 are part of each attribute, or used
once for all attributes. For example,
https://wiki.php.net/rfc/shorter_attribute_syntax#lack_of_nested_attributes.
Derek and Benjamin's RFC shows no nested examples. Are nested attributes
even a thing now or did they disappear in an earlier RFC? If they are, they
should be featured.


On another topic, parentheses and ending delimiters. I have heard Derek's
distinction, but if we're after a syntax with an ending delimiter then I
would propose compulsory parentheses, which means all syntaxes @@, @:, you
name it, would have one.

If that's unacceptable for solving the "ending delimiter" issue, then
document it in the RFC. It feels there is a lot bound up in the lexing,
either by PHP or by how different people read and understand code. I'm
stabbing in the dark for reasons because it's not been explicit - and it
ought to be.


This is not a comprehensive RFC, and while I'm ambivalent about syntax
(having swung between <<>>, @@ and #[] over time) I do not appreciate
feeling that it's being bounced through. Room 11 is not this list, and
discussions that happen there (as earlier messages talk about) provide
background and context that is missing when reading this RFC and not having
been part of those discussions.

P.S. the RFC introduction also states that *"The main concern is that @@
> has no ending symbol
> and it's inconsistent with the language that it would be the only
> declaration or statement
> in the whole language that has no ending termination symbol."*
> I had mentioned this in (https://externals.io/message/111312#111335)
> that this statement failed to give concrete examples of problems (e.g.
> parsing ambiguities)
> that the authors believe could be caused in 8.0 or in future releases.
> I'd also stated that I think an attribute is neither a declaration nor a
> statement,
> but that could be resolved by including the definition of
> declaration/statement used by the authors.
> There are various syntaxes in PHP with no ending symbols (`clone`,
> `public`, `yield`).
> (I doubt changing this will make a difference since many people prefer
> `#[]`/`@[]` for other reasons,
> but still consider that sentence to be misleading.)


Agreed.

Peter

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

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://externals.io/message/111312#111354
>
> What is the difference between mandatory parentheses giving:
>
> <><>(
> <><>(<>),
> 42
> )
>
> and:
>
> <>[<>(
> <>[<>(<>)],
> 42
> )]
>
> in terms of parsing, use etc?
>
> Peter
>

Anyone?

Why is the discussion fixated on [] rather than ()?

Peter

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

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:

<><>(
<><>(<>),
42
)

and:

<>[<>(
<>[<>(<>)],
42
)]

in terms of parsing, use etc.

Peter

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

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 to "have an objective look", and the only other text in the RFC
> makes a vague assertion about the lack of ending symbol which I still don't
> understand the significance of.
>

I have voted no because I asked a question about the ending delimiter and
why () didn't count. Another person asked a similar question and neither of
us got a reply.

Peter

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Peter Bowyer]

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 easy to spot the end of the word.
>

And if needed, make the parenthesis required. So @@Foo is illegal,
but @@Foo() is allowed.

Required parenthesis is familiar to most PHP programmers (functions,
classes following common coding conventions) - what's not to like?

Using "^" in the code demonstrations below as no one has proposed it and my
point isn't about #, << or @@ we get:

^Foo(
  ^Bar(43, "raa")
)

vs

^[Foo(
  ^[Bar(43, "raa")]
)]

To me the former is significantly more pleasant to read.

Is it difficult to parse?

Peter

Re: [PHP-DEV] 8.0 Feature Freeze happening today

[Peter Bowyer]

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 to say thanks to you and Sara for your hard
work in getting the next release of PHP ready. Much appreciated!

Peter

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

[Peter Bowyer]

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 right thing to do?
>

Wouldn't a use case be profiling code, to see if JIT makes a difference to
a specific function? So I can profile with JIT disabled globally and @@JIT
on specific code, modify my code and see if it improves the JIT performance?

I'm basing this on my experience with the @jit annotation in Numba (
http://numba.pydata.org/) where it's useful to see the effect on small
pieces of code.

Peter

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

[Peter Bowyer]

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 significant objections
> from maintainers of larger OSS projects due to the overhead it adds to
> maintaining backwards compatibility as it has now made method/function
> parameter names part of the API; a change to them would cause a BC break
> for any library users who decide to use the new feature.
>
> It is likely that the way this will shake out is that some maintainers will
> accept the additional overhead of including parameter names in their BC
> guidelines and others will not, this leaves users unsure if they can use
> the new feature without storing up issues in potentially minor/security
> releases of the libraries they use. This is not really an ideal situation.
>
> More pressing a point is that the current implementation breaks object
> polymorphism. Consider this example (simplified from one of my codebases)
>
> interface Handler {
> public function handle($message);
> }
>
> class RegistrationHandler implements Handler {
> public function handle($registraionCommand);
> }
>
> class ForgottenPasswordHandler implements Handler {
> public function handle($forgottenPasswordCommand);
> }
>
> class MessageBus {
> //...
> public function addHandler(string $message, Handler $handler) { //... }
> public function getHandler(string $messageType): Handler { //... }
> public function dispatch($message)
> {
> $this->getHandler(get_class($message))->handle(message: $message);
> }
> }
>
> This code breaks at run time.
>
> Proposals were made for resolutions to this issue however all of them
> require trade offs and could potentially break existing code.
>
> My proposal to resolve these two issues is to add the ability to rename
> parameters with a new syntax as follows.
>
> function callBar(Foo $internalName:externalName) {
> $internalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x);
>
> This allows both the above problems to be resolved, by renaming the
> internal parameter and keeping the external signature the same.
>
> I propose that the RFC would have two voting options.
>
> The first would be to implement it as proposed above, this would allow any
> parameter to be called by name regardless of the intentions of the author
> of the method/function and is closest to the current behaviour.
>
> The second option would be to use this syntax to make named parameters in
> userland code explicitly opt in. As such an additional shortcut syntax
> would be implemented: $: to designate a named parameter. eg
>
> function callBar($:externalName) {
> $externalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x);
>
> If a parameter is not opted in, a compile time error is raised:
>
> function callBar($externalName) {
> $externalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x); // Error: cannot call parameter $externalName by
> name.
>
> There are pros and cons to this second approach, on the one hand it reduces
> the usefulness of the named parameter syntax by requiring changes to old
> code to enable it (although this could probably be automated fairly easily)
> however it does provide a neater solution to the second problem in that, to
> prevent the runtime errors in the second issue example, every child class
> would need to use the rename syntax on it's parameter to prevent errors,
> whereas if we went down this route, the parent class could just not opt
> into the named parameter syntax and the code would function as expected.
>
> Another advantage is that with the ability to rename parameters using the
> opt in, we gain some flexibility to tighten up the LSP rules relating to
> named parameter inheritance.
>
> class Foo {
> public function bar($:param) { //... }
> public function baz($internal:external) { //... }
> }
>
> // OK
> class Bar {
> public function bar($renamed:param) { //... }
> public function baz($renamed:external) { //... }
> }
>
> // Compile time error cannot rename named parameter $:param (renamed to
> $:renamedParam)
> class Baz {
> public function bar($:renamedParam) { //... }
> }
>
> // Compile time error cannot rename named parameter $:external (renamed to
> $:renamed)
> class Baz {
> public function baz($internal:renamed) { //... }
> }
>
> While this would be technically possible with the first option (no opt in)
> it would break any existing code which renames a parameter as every
> parameter would be subject to these rules.
>
> I don't have Wiki karma so can't post this yet; but I want to get the ball
> rolling on discussion as feature freeze is coming up fast and if we want to
> go for the second option, that must hit before the named parameter syntax
> is in a tagged version 

Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Peter Bowyer]

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 realize that there is more at stake here than just "which
> syntax is prettier?" and choices that have a "closing tag" are technically
> more favorable, especially if we consider future extensions of the
> attribute system that may introduce additional ambiguities (e.g., Rust
> allows placing attributes pretty much everywhere in code -- how sure are we
> that there will be no unanticipated ambiguities?)
>

Thanks for this clear explainer. I hadn't appreciated the "no closing
delimiter" issues during the original vote, also picking @@.

As many other languages use '@' as their symbol, how do they handle or
avoid the whitespace issues?

Peter

Re: [PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void

[Peter Bowyer]

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 enforcing "void" for all constructors of a
> project for example. I would vote Yes on that.
>

Isn't this close to what the second vote "Allow void return type on
constructors/destructors?" does?

My understanding is that a "Yes" on this vote will:
1. Allow you to omit a return type (and therefore return whatever you want)
2. Explicitly add void return type

This doesn't do exactly what you ask for (to add any return type) but to me
is close enough; as these are meant to be void according to the PHP docs,
having it as the only explicit return type makes sense to me.

Peter

Re: [PHP-DEV] [RFC] \PHP namespace usage heuristics

[Peter Bowyer]

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

Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void

[Peter Bowyer]

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 than the BC break that would
have been caused if the proposed #[] attribute syntax had been chosen.

Peter

On Thu, 2 Jul 2020 at 22:12, Benas IML  wrote:

> Hey internals,
>
> I have opened the voting for the RFC, let's hope everything is going
> to be smooth :). If you have any other questions, let me know!
>
> RFC: https://wiki.php.net/rfc/make_ctor_ret_void
>
> Best regards,
> Benas Seliuginas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Re: [PHP-DEV] SQLite3, PDO/SQLite and driver specific methods

[Peter Bowyer]

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 types, and avoid any magic.
>
> If you (or anyone) have the time to work on this, that would be fantastic.
>

Well, I gave it a go this week! I last wrote C 2 decades ago, and those
were simple programs. Digging into the PHP source code is a fun challenge.

I worked out how to create a new class [1] and to get PDOSQLite to extend
PDO [2]. Extending PDO took some thought; Reflection extension does it but
all classes are defined in one file. SPL, DOM etc also do it with their
classes. Eventually I saw how SimpleXML did it and was able to apply that.

I've got stuck with adding `PDO::connect('sqlite:...')` [3]. Can someone
take a look and give me advice?

Peter

1.
https://github.com/pbowyer/php-src/commit/bcbdce9134e695d4926d11f2fa1a855b3237db6e
2.
https://github.com/pbowyer/php-src/commit/90a9c20fa1f8a626df8636f6c9e4f974fd789daf
3.
https://github.com/pbowyer/php-src/commit/51654eeae9407dc8991d62155719fbfea211f735

[PHP-DEV] SQLite3, PDO/SQLite and driver specific methods

[Peter Bowyer]

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
https://github.com/php/php-src/pull/3368. In the pull request Christoph M.
Becker wrote on 8 May:

This PR is still unresolved. The problem is that adding driver specific
> methods to PDO via the currently existing mechanism (basicall `__call`
> like), has faced some strong oposition, so this should be discussed on
> internals. It probably would make sense to start some general discussion
> about this issue, and to hopefully come to a solution, so driver specific
> functionality could be added to PDO in the future.
>
[Link: https://github.com/php/php-src/pull/3368#issuecomment-625731098]

In light of this comment, I'm emailing the list to start a general
discussion about this issue.

As alluded to earlier, there is a maintenance burden, and for users the
lack of parity between the two extensions can be an issue.

PDO is well established as providing a standardised access layer across
databases. SQLite requires extensions to be loaded to gain feature parity
with other databases (e.g. to load geospatial functions) and since it is
not a database server these have to be loaded at runtime. PDO has three
sqlite-prefixed functions (https://www.php.net/manual/en/ref.pdo-sqlite.php)
but not one to load extensions.

Is it a problem to add one?

If it is, how can we change and improve the current situation?

Peter

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

[Peter Bowyer]

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, statements, behavior, whatever; I just need to listen and try
> to behave in a way that they feel safe. (And of course there are aspects
> I can't change.)
>
> I think the same applies to this topic, and it's important to get a
> common understanding of the problem space. (Let's talk about the
> solution space afterwards.)
>

Thomas's post has been ignored by everyone but IMO is the most important in
the thread. [HT to Peter Stalman who expressed a similar thought]

I am a white man. It is not for me to say what is best for others - how
colonial and offensive is that??

So if we want to do this, let's:

1. Ask the black community what they find offensive in PHP
2. Listen
3. Prioritise the responses and judge which are feasible to act on
4. Act


> (I'm not sure if we need to raise this questions in a broader context
> regarding other groups of people. I don't want to open a can of worms.
> But I don't want to forget about other groups.)
>

We should consider all groups of people, but my opinion is it's too
difficult a task to do right now.

Peter

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Peter Bowyer]

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 C#'s [attr]
syntax and C++'s  [[attr]] are impossible due to PHP's short array syntax.

Peter

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Peter Bowyer]

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 system. We'd be forced to go with things
> like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to
> me, as we're just reinventing namespaces to avoid using them...
>
> As such, I would suggest to introduce a common namespace for all attributes
> provided by PHP. This means we'd have Attributes\Attribute,
> Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay
> with the PHP\Attributes\Deprecated variant, but that's a separate
> question).
>

This is the best real-world argument in favour of PHP namespace in core
that I've heard.
https://wiki.php.net/rfc/php-namespace-in-core

If we don't want to introduce classes in the global namespace, it makes
sense to have a reserved PHP namespace we use.

Peter

Re: [PHP-DEV] Deprecating uniqid()

[Peter Bowyer]

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 elements, or suffixes for table names,
> or
> > even file names; applications that really just need a few alphanumeric
> > characters that are different each time.
> >
>
> Seems like UUIDs would be a good fit for all of these.
>

For file names, absolutely. In many cases they have to be unique across all
processes, and that's important. For the others I say a UUID is only a good
replacement if taking a substring of a UUID is going to be unique.

Take HTML element IDs. My experience is UUIDs (random data) doesn't
compress well, and so shorter unique strings are preferable (also for
reading the HTMl when debugging). The number of elements you're adding IDs
to matters: if you add 10 then the UUID overhead is negligible; if you're
adding to thousands it's different.

For table name suffixes (if needed), the maximum length of a table name is
64 characters in MySQL. It's easier to cope with all systems if the table
name pre-suffix can be more than 28 characters (27 if you put a separator
between the table name and the suffix)

For these reasons, I support adding a nice way to generate semi-unique
data, preferably of user-defined length, and that doesn't have the
drawbacks of uniqid().
And deprecating uniqid().

Peter

Re: [PHP-DEV] Re: [VOTE] Attributes v2 RFC Vote is open

[Peter Bowyer]

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 and priorities
disrupted for many people.

Best wishes,
Peter

Re: [PHP-DEV] Re: [VOTE] Attributes v2 RFC Vote is open

[Peter Bowyer]

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 (
https://externals.io/message/109713#109717).

Peter

Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis

[Peter Bowyer]

>
> For details, see the full writeup:
>
> https://hive.blog/php/@crell/improving-php-s-object-ergonomics


An excellent writeup, thank you Larry.

Peter

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Peter Bowyer]

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. The chosen API. We have an OO approach, but headers and query parameters
are accessed through an array-style mechanism. I'm not a fan of the way
everything maps onto ServerRequest, with certain $_SERVER vars promoted to
be part of it (but not all AFAICT).

2. The OO-ish approach. For a core feature which will be around for 20+
years I would like a pure(r) OO approach taken, and time to be taken to get
that right. What you have is pragmatic, but as I say in (1) not something
I'm a fan of. Rowan Tommins on 18 Feb 2020 at 20:21 expressed this well
(link: https://externals.io/message/108436#108661).

3. WRT the RFC:
a) there is no section on where this came from. With your involvement in
PSR-7 it looks to be an area you've given much thought to. Why did you
develop ext/request? What problem(s) did you see that this is the answer
to? I skimmed the thread but didn't pick out a clear answer to this.
b) Did you look at how other languages and/or frameworks deal with requests
and responses, and was there inspiration and lessons you took from their
successes (or failures)? [For me this is a key omission in most PHP RFCs]

Thinking about porting existing codebases across, ServerRequest holding
copies rather than references would make it hard to interop with existing
code using the superglobals. I've had this rewriting legacy apps that use
$_SESSION and the new framework uses an OO session handler; it's not fun
but with references can usually be made to work. In this case, what would
the migration path look like? Johannes Schlüter commented on this on 24 Feb
but I didn't understand his comment (link:
https://externals.io/message/108436#108737).

In summary, I like the idea of steering people away from superglobals,
appreciate the work you've put in, and am not persuaded by the approach.

Peter

Re: [PHP-DEV] Proposal for a new basic function: str_contains

[Peter Bowyer]

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, string $needle): bool
>
> What are your opinions on this proposal?
>

In principle, yes. There are a couple of considerations first, like how you
plan to handle case-insensitive matches; and previous discussions for this
and the wider context of related string functions:
https://externals.io/message/106162
https://externals.io/message/100142
https://externals.io/message/94787
https://wiki.php.net/rfc/add_str_begin_and_end_functions

Peter

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

[Peter Bowyer]

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 they do exactly what
> people want.
>

I agree. It isn't wrong to use MD5 or SHA1 in the right situation (or even
CRC32). The documentation can tell people when they can use these
algorithms, and when they must not think about using them. Mark them in the
documentation as "RECOMMENDED DO NOT USE" and guide people away.

Peter

Re: [PHP-DEV] Add viable long running execution model to php 8

[Peter Bowyer]

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 different name wouldn't make the migration any easier.
>

You're absolutely right. The difference I'm thinking is that if there is
built-in support in the language, frameworks will embrace it. At the moment
I'd need to make my own fork to add compatibility with Swoole et al (or use
one of the experimental but unsupported forks out there), which isn't
attractive.

Peter

Re: [PHP-DEV] Add viable long running execution model to php 8

[Peter Bowyer]

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 generally introduces network and processing overhead - HTTP
> headers and parsing for setup + framing protocol handling.  In many
> cases, a simpler "JSON blob per newline" approach works just as well (if
> not better) and can afford better isolation and performance models (i.e.
> not everything has to be WebSocket).  There are plenty of flaws inherent
> to the design of the WebSocket protocol itself (some are
> security-oriented) and so anything built on it shares those flaws.
>

This critique of WebSockets sounds similar to that of https://mercure.rocks/,
which uses HTTP/2 and Server-Sent Events instead of WebSockets.

I'm interested in WebSockets because I've been following the development of
Phoenix LiveView [1] for the last 13 months. Something similar in PHP would
be awesome (though the statelessness of PHP will complicate matters), but
when I looked at Swoole et al they wouldn't work with my existing
framework-based code. An approach that avoids rewriting, like some form of
built-in support in the language would be good for this alone.

Peter

1.
https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript

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

[Peter Bowyer]

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
> 2020-02-11.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable interface

[Peter Bowyer]

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 ArrayObject and/or the related associated
> interfaces such that the objects can be used interchangeably with a
> built-in array
>
> I completely agree. I would love to see anything implementing ArrayAccess
> able to be used in any of the array functions.
>
> This might be a way-out-in-left-field concept, but if we went down this
> path, perhaps a PHP array could become an object internally (i.e.,
> ArrayObject) without changing the way it works in existing code? Then,
> if/when generics are introduced, a PHP array would already be a class to
> which a generic type parameter could be applied.


I agree with Mike & Ben. Another voice in support of this.

Peter

Re: [PHP-DEV] [RFC] anti-coalescing-operator

[Peter Bowyer]

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 suspect he intends to RFC properly soon.  As long as the topic is at
> hand, what's the general appetite for it?  Should I bother polishing the
> turd?
>

It would be the best Christmas present ever.

Well. Almost.

Peter

Re: [PHP-DEV] Re: [RFC] Union Types v2

[Peter Bowyer]

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 runtime checks, would an ini setting where they can be
completely disabled be feasible? So during development and in production
when the performance decrease doesn't matter, I can have the full runtime
type checking. But when absolutely needed, the checking can be disabled.

Peter

Re: [PHP-DEV] Defining the PHP Group

[Peter Bowyer]

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:
> https://www.php.net/credits.php


Respectfully, this is a list of people who are identified as part of the
PHP Group.

My understanding is copyright has to be vested in individuals or
legally-recognised entities. The PHP Group is neither of those. The
wording  "Copyright The PHP Group" is different to saying "Copyright the
individual contributors (hereafter referred to as "The PHP Group").

This led me to check that contributors to PHP do not have to assign
copyright to the PHP Group (I checked
https://github.com/php/php-src/blob/master/CONTRIBUTING.md
).
So what are the PHP Group holding copyright over?

As ever I welcome being set right if this is inaccurate.


> > And more
> > importantly, how would it defend or deal with a copyright infringement if
> > "The PHP Group" is not a recognised group or legal entity?
>
> Thankfully, copyright infringements are practically irrelevant as far as
> the PHP license is concerned.  License violations are also pretty much
> irrelevant, with the only practical exception being someone breaking the
> clause that requires them not to use the name 'PHP' to promote a derivative
> product.


I'm pleased that has been the case.  Long may it continue.

Peter

Re: [PHP-DEV] Re: [RFC] DOM Living Standard API

[Peter Bowyer]

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 about the
> reasonability of the choices?
>

I don't have feedback, other than to ask what choices other languages have
made when bringing in the DOM Living Standard API?


> Also the section on "Not adopting Nodes for now" is new and I need some
> feedback on this issue: To keep the proposal slim with respect to changing
> existing behavior, the improved behavior of the DOM Living Standard over
> Level 1-2 tof automatically adopting nodes instead of throwing a WRONG
> DOCUMENT DOMexception is not considered for now. Do you think this is a
> reasonable approach to go forward with?
>

If I understand correctly, the issue is the behaviour of a method has
changed significantly.

If not implemented in PHP 8, where BC breaks are expected, when would be a
better time?

Would deviating and implementing the new behaviour with a different method
name e.g. appendAndAdoptChild(); or guarded by a version flag (so users
choose whether they want the 'Living' behaviour or the 'Level 2' behaviour
in this method) be options?

Peter

Re: [PHP-DEV] Defining the PHP Group

[Peter Bowyer]

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 clarify what exactly is the purpose of the PHP Group
> today, does anyone want to attempt to do that ?
>

Joe, I applaud this move.

As a non-American and so used to a different legal system, I have a further
point I would like clarified: the PHP website and PHP license say
"Copyright the PHP Group" (https://www.php.net/copyright.php,
https://www.php.net/license/3_01.txt).

How can an undefined group have copyright vested in it? And more
importantly, how would it defend or deal with a copyright infringement if
"The PHP Group" is not a recognised group or legal entity?

Peter

Re: [PHP-DEV] Changing fundamental language behaviors

[Peter Bowyer]

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 important to consider the impact of a change,
> including for the Wordpress community. However, I think most people agree
> that the quality of Wordpress code and Plugins is highly debatable. I don't
> like the idea of not being able to progress because Wordpress users won't
> upgrade PHP.
>

This raises an interesting, tangential point. Who is PHP for?

One can argue that WordPress, with it powering 34% of the web (source:
wordpress.org) represents more than 50% of PHP users, and therefore
aligning the language to how they use it would be sensible, as they are the
majority of users. PHP and WordPress have had a symbiotic relationship, the
success of one increasing the success of the other.

Those who wish PHP was more advanced and different (and I count myself
amongst them) do well to remember that PHP has become extraordinarily
successful in spite of the flaws now perceived. It's a good language that
fills a niche even server-side JavaScript hasn't usurped. There is no shame
in a language staying true to its roots, plateauing and eventually dying a
death (cf Perl 5). I don't want that, but it's a valid route. And the
communities that use PHP in a way many on this list look down on will be
thankful to continue to have a language they can use, can hack with, and
get stuff done. Even if there's a few extra bugs.

The rest of us, meanwhile, have the opportunity to use a programming
language that's closer to whatever we feel is a "proper" language (a vibe I
pick up in the "they look down on us" and "I'd rather PHP was more like X"
messages). If you're going to have to justify upgrading your code, why not
propose a rewrite in another language? One can sell it on the fact it won't
have the flaws regularly brought up on this list - like warnings instead of
exceptions, or two opening tags. Or, despite the fuss on-list, do those who
decide how the next project will be written/the current one rewritten, not
care to the same extent, and other factors will influence their choice?

Personally I cannot wait for new features to be added, but feel our
heritage is as important as the future. Jordi expresses my feelings, and I
quote him:

Breaking BC here does not seem to bring much. If there are cases where
> enforcing strictness might allow better JIT for example, then I could
> see the case being made. But simply turning working code into fatally
> failing code isn't progress. [...] So what do we gain exactly?
>

Peter

Re: [PHP-DEV] [RFC] Union Types v2

[Peter Bowyer]

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 `string|__toString`.
`string|Stringable` is more readable IMO.

Peter

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Peter Bowyer]

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 compromise.
>

Is there any technical reason PHP can't go the transpiler route? Let
everyone experiment with their own preferred changes, and pull the best
ideas, once proven, into core PHP?

Peter

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Bowyer]

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 versions needs to be taken into
> consideration.
>

It does indeed, and this approach was proposed by myself and another
person.

The approach was: add the deprecation notice in PHP 8, and remove short
open tags in PHP 9 or PHP 10 (purposely left vague to get more support for
the idea - as getting the deprecation underway is the most important move).

It met with deafening silence.

Peter

Re: [PHP-DEV] PHP direction and governance [was: Re: [PHP-DEV] P++: FAQ]

[Peter Bowyer]

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 codifying
> such things - as soon as you have written The Rules, next thing that
> happens is rule lawyering and instead of considering arguments on their
> merits, people start arguing whether raising this or that proposal
> violated the Rules and whether their opponents should be silent because
> The Rules say so. This is tempting because arguing rules is usually
> easier than arguing merits (The Rules are always the same and the merits
> are always new), but winning on the rules is never satisfactory and
> rarely healthy, because the other side always feels they have not been
> properly heard.
>

I understand and agree this is a danger with rules, particularly
over-lawyering. Where I disagree is that this is worse than the current
situation, but I'm OK with that as we seem to have different philosophical
outlooks. I suggest there is an issue of balance, to be too far towards
either outlook is not a good situation.

I disagree that (as I take away from your last sentence) the current
approach is better because it means people feel they have been properly
heard. I can think of recent messages on the list from people saying that
they don't feel heard.

Perhaps we can have more consensus around the questions "Are things going
well on this list / with the PHP project in general?". If we do think the
discussions here have not been ideal and some direction (which in an
individualistic meritocracy is not easy) would help, then the follow-on
question of "How can the situation be improved?" is of greater shared


> But do we really want to pre-commit one being always more important than
> the other in any case, no matter what? Do we want to pre-commit never
> considering specific case on its merits and always be satisfied with
> "The Rules say A more important than B, therefore function has to be
> removed and you can't argue it's important because The Rules are
> supreme, kneel before The Rules!" I certainly wouldn't feel satisfied
> with such outcome. We can reflect certain philosophy and premises we
> consider preferred, but we shouldn't pre-commit to it excluding discussion.
>

I feel you're interpreting things in a more black and white way than I did
by changing the terminology to 'Rules'. I didn't use this word, and neither
did I claim they were absolutes. Your last sentence is what my email said
to my reading.

The problem I see is that if we don't commit to anything, then we stand for
everything and nothing.


Any thoughts on governance and the lack of consensus over who should/should
not have a say in what happens?

Peter

Re: [PHP-DEV] P++: FAQ

[Peter Bowyer]

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 be the numerical, scientific and linear
algebra libraries that's driving its popularity.

I agree PHP has a way better runtime and it is frustrating to see this
happen.


> It’s strange given how much better it actually runs (really being unbiased
> here).
>

If PHP doesn't have the libraries people want, and if PHP is perceived as a
web scripting language rather than a general-purpose dynamic language, then
the better runtime isn't going to convince a large audience that it's the
best tool for the job.

Peter

[PHP-DEV] PHP direction and governance [was: Re: [PHP-DEV] P++: FAQ]

[Peter Bowyer]

[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 week.  A few years back,
> Anthony Ferrara proposed developing an actual PHP mission statement to help
> resolve such debates over direction and was resoundingly rejected.  Rightly
> or wrongly, to speak of "PHP philosophy" as a thing one can actually
> reference is simply not possible.
>

I have been working on a proposal for a PHP manifesto / mission statement.
I did not know it had been proposed before. [I haven't tracked down
Anthony's proposal - if anyone has a link, I'd appreciate it]

I started for the same reason: to help the community pull together and
argue less, by having a codified set of values.

On this list there are many different factions, all with their own vision
for PHP. If everyone is fighting to "win", it's an unpleasant, tiring
environment, turns people off contributing, and those who "win" can be
those who keep going the longest, not those with the best idea.

I saw a manifesto helping like this:

"Consider a proposal to remove a function from PHP. If PHP had a manifesto,
heated discussions could be minimised:
  * Does the manifesto say that maintaining backwards compatibility is more
important than cleaning up the standard library? Removing it is not inline
with PHP’s vision.
  * Does the manifesto say that rarely-used functions should be removed to
make the codebase lean? Removing it is inline with PHP’s vision."


Observing the project, I am not hopeful that anything like this could gain
traction without an overhaul of PHP's governance. Someone or some group
would have to have the deciding vote on what went in the manifesto.

In the last few months I have seen:
  * Core contributors should have more/the final say on RFC votes
  * The PHP user-community should have more say on RFC votes
  * The PHP Group have authority over the project
  * The PHP Group do not have authority over the project
  * A longstanding contributor feels they have a leadership position
  * Others feel the longstanding contributor doesn't

I am stating these neutrally, not judging them. Neither am I aiming to
misrepresent positions. If you feel I have, I'm sorry.

I am highlighting that there is no consensus here. I get this is the way
the project has always run (I think of it as the "Linus Torvalds and the
Linux Kernel" meritocracy approach). But: people don't seem happy.

Is there appetite for change?


> To end on a positive note, while I agree that there is often a tension on
> such questions I think PHP has been remarkable in how well it's navigated
> it.  I don't know any other language that has managed to evolve as much as
> PHP has from 5.3 onward with so little relative BC breakage.  The
> new-features/breakage ratio for modern-era PHP is, I think, bloody amazing.
>

I agree, and want to say a big "Thank you" to everyone who made that
happen. The PHP-userland community is too silent about the good things in
PHP, and you who bring the language about deserve way more praise than you
get.


Finally, I am going to wait at least 6 hours, ideally 12 before replying to
responses, and I encourage you to join me in this. My knee-jerk replies can
be more argumentative than I mean them to be, and by slowing down the
conversation I hope we can have a reflective and thoughtful discussion.

Peter

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Bowyer]

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 results in a lot of confusion, and
> frustration.
>

Documenting the project structure would also be helpful.

When the PHP Group was mentioned I went hunting for details. I found a list
of names at the top of https://www.php.net/credits.php but nothing covering
what their role or authority is.

Peter

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

[Peter Bowyer]

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 change to reevaluate the proposal in light of the new
> arguments that have been brought forward. I guess that next time I'll just
> go ahead and merge things.


On Wed, 24 Jul 2019 at 04:51,  wrote:

> - The motivation for removing short tags today is a lot weaker than the
> motivation was not to add it in the first place back in 1998 (XML being a
> lot less important).  This makes for an unreasonable basis for deprecation.
>

I think it fair to say:

1. The RFC to remove short open tags passed
2. The backwards-compatibility break is contentious

I move an alternative motion: that short open tags do not change in PHP
7.4, throw a deprecation warning in PHP 8.X, and what happens next (e.g.
removal) is left for a future, PHP 9 RFC. The manual is updated to say they
are deprecated and will be removed in future, to dissuade new usage.

Sure, this is "kicking the can" down the road. It's also a proposal I hope
both sides can support.

Peter

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

[Peter Bowyer]

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 following "tradition", like stri_starts_with
> & stri_ends_with or str_istarts_with & str_iends_with? That would
> follow strstr / stristr and str_replace / str_ireplace.
>

I would vote yes with that naming. It's a damn silly tradition, but it's
what PHP uses for other functions, and keeping consistency is better than
improving individual functions.

Peter

Re: [PHP-DEV] [RFC][VOTE] Deprecate curly brace syntax for accessing array elements and string offsets

[Peter Bowyer]

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 any consideration given to a split vote, voting on the array
and string deprecations separately?

For others interested, the history of this deprecation going back to 2005
is found at https://externals.io/message/38153

Peter

Re: [PHP-DEV] Removing mysqlnd stats from phpinfo

[Peter Bowyer]

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 progressive enhancement, so people with JavaScript disabled
see everything.

Though personally I have no problem with the length of the page; I use the
browser's in-built "Find" tool to jump to where I need to go.

Peter


On Thu, 16 May 2019 at 22:41, Johannes Schlüter <
johannes.schlue...@oracle.com> wrote:

> On Mi, 2019-05-15 at 19:01 +0200, Pieter Hordijk wrote:
> > Hey internals,
> >
> > when there is support for mysqlnd the `phpinfo()` page hows the
> > entire list of available mysqlnd stats.
> >
> > Do we really need to show the stats here? It makes the page
> > unnecessary long and somewhat annoying to scroll past for no obvious
> > (to me) reason it to be there.
> >
>
> In a way it gives nice attention to the fact thy are there. But I guess
> they don't have to be there. If this makes he page too long removing is
> fine.
>
> johannes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] open_basedir?

[Peter Bowyer]

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 guarantees we could not deliver.
>

Yes.


> In general, I think we should slow down a bit (actually, a lot) with
> removing things from PHP. We've already accumulated a lot of BC baggage
> here, and if we want PHP 8 to become the version of PHP that an average
> developer can target without hearing "yeah, we're planning to upgrade
> sometimes in the next 2-3 years, probably, maybe", then we should slow
> down with the removals.
>
> PHP 7 had rather short list of removing things, and most of them very
> marginally used. And that IMHO worked well. Here we're talking about
> things that are used - on my estimation - much more widely. open_basedir
> particularly is not that bad in this regard, because likely no app
> critically depends on it being there - so it's more of a generic comment
> about what I am seeing on the lists nowdays, where tons of removals and
> global overhauls with enormous BC costs are proposed.
>

I agree with Stas.

I support a campaign of education by doing Nikita's a) & b), with the
addition of:

c) highlighting the performance impact (particularly if it can be
quantified)
d) updating the PHP.ini comment to say it is not recommended to enable,
with details of a) b) & c)
https://github.com/php/php-src/blob/master/php.ini-development#L295-L300

I will vote against removing if it comes to a vote.

Peter

Re: [PHP-DEV] RFC Process: more productive conversations

[Peter Bowyer]

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 discounted?
>

During the experiment, not at all.

I'm not presupposing any outcome, and if commenting was kept after the
experiment and if it was to have an effect like you describe, it would need
to go through the RFC process and be approved.


> What is the goal of the experiment?
>

To see if there's a basis in practice for the concern expressed around who
can vote and the problems it may/does cause;
To see how people respond to being asked to comment, explaining their
choice of vote;
To see what impact commenting has on the voting process.

It would need to be run for a set period of time; perhaps best measured in
"Number of votes carried out". Completely guessed without looking at past
vote frequency, but say 4 months or 10 votes, whichever is longer.

Peter

Re: [PHP-DEV] RFC Process: more productive conversations

[Peter Bowyer]

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
> comment there's no way to vote.
>
> That way all the information would be readily available in the RFC and no
> one would need to add comments after an RFC was voted upon. Because IMO
> that information as well as the process that lead to acceptance of the RFC
> are also important to afterwards make clear why that feature was
> implememted the way it was. So all RFCs and also all voters would be
> treated the same.
>

Yes, that is the system I would like. Whether the comments are hidden
during voting or visible I have no strong feelings - but I would like a
comment to be required to vote. As you say it is useful history.

People may enter nonsense into the comment field. They may paste in their
message(s) from internals. I'm OK with any of that as it's an experiment.
If it's not useful, we can stop asking for a comment.

Given the concerns raised around voting, it would be interesting to see the
effect this has.

Peter

Re: [PHP-DEV] RFC Process: more productive conversations

[Peter Bowyer]

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 is how I have perceived the
> intentions of people who have asked for 'no' voters to explain their
> vote.
>

It also ties in with the view previously expressed that we should restrict
voting rights because (my paraphrase) "too many people can vote for
something they don't understand and won't have to maintain".

Asking people to say why they voted the way they did helps explore this:
can people give a cogent reason for their vote?

Peter