> On Oct 10, 2022, at 8:04 PM, David Gebler <davidgeb...@gmail.com> wrote:
>
> This is what's bothering me. Either these "experimental" features have
> passed RFC and will be part of the language, as you've said above, or
> they're actually experimental i.e. not finalized and implementing behaviour
> and syntax which may be subject to change or even dropped entirely
> depending on the feedback cycle.
If they are not experimental and their usage is finalized, then they are
in-fact approved and they would be absolutely no different from the existing
RFCs today.
You cannot have experimental features unless those features have the potential
to not be included in the future language and/or those features have the
potential to be improved before they are finalized. Otherwise, what's the point?
BTW, I googled several different phrases trying to find a horror story in
Node.js because of their experimental features, but the only thing I was able
to find was people glowing about the features that are currently experimental
and/or the excitement when a feature graduated to fully supported, for example:
https://nodesource.com/blog/experimental-features-in-node.js/
Maybe you can find examples of downsides of having experimental features in
Node.js (or some other language/platform) that I was unable to find? If so, it
would be instructive to learn from their experiences.
> Using the trivial json_validate() example (although as others have said, a
> simple new function is probably a bad example),
(As an aside, I disagree that a new function would be a bad example. I think it
would be a good use-case for experimental features because of how decoupled it
would be from the rest of the language, and it would help to see if a lot of
people use the function before committing to including it.)
> If it's the former, the library can just check if PHP >= 8.3 and fall back
> to userland implementation / polyfill for earlier versions. This is just
> what we have now, where approved new features are part of a versioned
> release.
Not all potentially useful functions can reasonably be implemented in userland
PHP.
> If it's the latter, everyone touching the experimental version, directly or
> indirectly, may have to rip out and change code later which renders the
> work they've put in to use the experimental feature in their code pointless.
That is not a hard software engineering problem. Software developers have been
isolating 3rd party dependencies for decades. There's no reason why developer
could not isolate (most) potential experimental features in the same way.
> I'm inclined to suggest if you opt in to an experimental language feature,
> you are by definition making at least an implicit declaration that you know
> what you're doing,
You speak of people "knowing what they are doing" as if it were a binary thing,
i.e. they know what they are doing or they do not. Let me use an analogy for
you here to try to make the counter point.
There are a handful of doctors of the world's leading heart surgeons. They
absolutely "know what they are doing." But if I have brain cancer and need a
tumor excised, I would not let any one of those doctors touch me unless they
were also celebrated as a brain surgeon. I am guessing you would feel the same.
Similarly, someone can be an excellent software developer but not have strong
DevOps or sysadmin skills. In my 10+ years working with PHP I met, knew, and
worked with *many* people like that. And for many years, *I* was one of those
people.
> so the idea people using these features wouldn't have
> the skills to spin up a container or install something on a VM doesn't
> convince me, personally.
Not every developer is a polymath. Some are excellent at writing software but
cannot configure a server or a VM or Docker container to save their life. In
my LinkedIn I could probably give you a list of 100 developers what that would
apply to.
IOW, they are a lot of excellent heart surgeons out there but they just don't
know how to fix a brain.
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
