On Tuesday, July 10, 2018 6:56:24 AM CDT Zeev Suraski wrote: > On Tue, Jul 10, 2018 at 2:06 PM Pedro Magalhães <m...@pmmaga.net> wrote: > > On Tue, Jul 10, 2018 at 11:33 AM Zeev Suraski <vsura...@gmail.com> wrote: > >> I've also given several examples - some of them arguably quite bigger > >> than > >> this proposal - where we sat on code for a very long time (multiple years > >> even) in order for it to be included in a major version, and not a minor > >> one (phpng, JIT, FFI) even though technically they could go into the next > >> available minor. > > > > Hi, > > > > I'm trying to understand this argument better but there is something I'm > > missing. Why would a feature like JIT (which would be transparent to the > > user AFAIK) need to wait for a major other than marketing reasons? > > Sorry in advance for the slightly off-topic question. > > Major versions are in many respects "marketing" events. They're an > indicator that big changes have happened in the language, big enough to > warrant a change in the major version. > It's a relatively recent evolution that we decided to only make it possible > to break compatibility in major versions (and it's a very positive > evolution, without a doubt), but either way - compatibility breakage has > never been the motivating factor behind a major release. Major releases > enable compatibility breakage, not the other way around. > Major features have always gone into major releases (with one notable > exception - PHP 5.3, which many argue was a de-facto major release). > > While 'marketing' always played a role in designating a certain version as > major - getting people more motivated to upgrade, bring positive vibes and > attention around the language, etc. (as was the case with 7.0) - since the > formal release process and the policy change to only allow compatibility > breakage in major versions - these compatibility breakages actually, to a > large degree, 'piggyback' on the major new features. To make it more real > - what would the migration to PHP 7 look like if it was all about the > compatibility breakages, and not the performance boosts or for that matter > - scalar type hints? Both of these (performance boosts and scalar type > hints) could easily go into 5.7 from a purely technical perspective. > > Zeev
While the marketing angle is valid, Zeev, it seems predicated on the idea that
there won't be any other major new-and-cool features developed between now and
8.0. I'm reasonably confident that someone will find some user-facing
exciting thing to improve between now and 2020. I know some people have plans
they're already working on.
Conceptually, as Nicolas and you have both hinted at, PHP 7.x is the series
where "typing got real". From a user-facing/marketing perspective 7.x is all
about performance and typing. That's the through line. Including typed
properties in that makes logical sense, marketing-wise, and would be a fitting
capstone to the 7.x series in that regard.
That's true regardless of whether typed properties go into 7.3 or 7.4; if
given the timing they need to wait for 7.4 to have some extra polish done
that's entirely reasonable, IMO, and doesn't change the underlying point.
However, mixing "no new features in 7.4/8.0, just the engine changes" with "we
need a big showy thing in 8.0 to help sell it", er, feels like a
contradiction. It makes it sound more like "borrowing" a feature from 7.3
(typed properties) for 8.0 for purely marketing purposes, and then also
blocking any other features, so that we know 2 years out "the only interesting
thing in 8.x will be typed properties, because that was written when 8.x was
still just a twinkle in the eye but we sat on it". That feels very
disingenuous.
I am sure that's not your intent but those two statements together ("minimize
features for 8.0" and "save this feature for 8.0 for marketing") just don't
fit together in my mind in a nice way.
--Larry Garfield
signature.asc
Description: This is a digitally signed message part.
