Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97067
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.65 as permitted sender)
MIME-Version: 1.0
Sender: kalle.php@gmail.com
In-Reply-To: <CADyq6sLmAXsZiXoA9ewuv_LmZnQuozfDCQNwXs3G2=3Yzc5DGA@mail.gmail.com>
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
 <94840a5a-39e2-5255-e9c5-c011f00d392b@gmail.com> <CAJW__o2ffCSRPTZ+QojSBoL6YA0ZgP_iGtW00WHD104aCziWEg@mail.gmail.com>
 <CADyq6sLmAXsZiXoA9ewuv_LmZnQuozfDCQNwXs3G2=3Yzc5DGA@mail.gmail.com>
Date: Sat, 19 Nov 2016 19:29:31 +0100
Message-ID: <CAJW__o0ziuVTOfTPGQ5uxWx_L-ovAuz+hy-bs8XSjXspGQgmBg@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2
From: kalle@php.net (Kalle Sommer Nielsen)

Hi Marco

2016-11-19 18:56 GMT+01:00 Marco Pivetta <ocramius@gmail.com>:
> That will end up breaking the "expected" (because it's not that way anyway,
> but almost) SemVer approach, diminishing the trust from consumers in any
> kind of upgrade.
> Most of the current open-source libs out there are trying to push for SemVer
> - having PHP not following that seems like a huge mess to me.

I don't think a SemVer approach will work for PHP in its current
state, not to say that it won't but the way that some of these things
are implemented, it makes complications for further internal
improvements that comes with each major/minor release.

Take the "Forbid Dynamic Scope Introspection" RFC you voted yes to,
which is implemented in PHP 7.1, sure, this one in particular is on
the path down to pandora's PHP edge case box, but without it we would
have lost speed gain optimizations (faster PHP by upgrading) and have
to stick around with code that could lead to pitfalls, hard to debug
code or nasty crashes. I do understand that we have to draw a line in
what is sensible to deprecate and remove in favor of what and when,
but keep in mind how large a userbase PHP serves, hundreds of millions
of websites, millions of developers and yet we are maybe about 20
active developers who contribute code to PHP's internals on a regular
basis. Time, resources and energy for keeping things in closed state
for so long where we cannot change anything is not fun or motivating
for contributing.

(And I would rather not that PHP felt into a version scheme similar to
that of Chrome where in December we could have PHP 42.0.)


[1] https://wiki.php.net/rfc/forbid_dynamic_scope_introspection


-- 
regards,

Kalle Sommer Nielsen
kalle@php.net