Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102731
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 64.147.123.24 cause and error)
To: internals@lists.php.net
Date: Tue, 10 Jul 2018 14:18:20 -0500
Message-ID: <8062036.rYxh8IFiYi@vulcan>
In-Reply-To: <CAJHtznybD1L5MnzhcNB_Kb0UPgag3zbrpOtr5zbfWCehx++R6w@mail.gmail.com>
References: <CAF+90c_L7S+EB8YxdNNpNZ7NhhYwCbwEw5_TSnSwUNN-zLVvCg@mail.gmail.com> <CAJd4=YYTP0caBhQda1HheiamHPtvO2XqXN4R=DgWF1iMdC7DeQ@mail.gmail.com> <CAJHtznybD1L5MnzhcNB_Kb0UPgag3zbrpOtr5zbfWCehx++R6w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart19634238.YjFZB9JIL8"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] [RFC] Typed Properties
From: larry@garfieldtech.com (Larry Garfield)

--nextPart19634238.YjFZB9JIL8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Tuesday, July 10, 2018 6:56:24 AM CDT Zeev Suraski wrote:
> On Tue, Jul 10, 2018 at 2:06 PM Pedro Magalh=E3es <mail@pmmaga.net> wrote:
> > On Tue, Jul 10, 2018 at 11:33 AM Zeev Suraski <vsuraski@gmail.com> wrot=
e:
> >> 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 ye=
ars
> >> even) in order for it to be included in a major version, and not a min=
or
> >> one (phpng, JIT, FFI) even though technically they could go into the n=
ext
> >> available minor.
> >=20
> > Hi,
> >=20
> > 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.
>=20
> 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 possib=
le
> 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).
>=20
> 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.
>=20
> Zeev

While the marketing angle is valid, Zeev, it seems predicated on the idea t=
hat=20
there won't be any other major new-and-cool features developed between now =
and=20
8.0.  I'm reasonably confident that someone will find some user-facing=20
exciting thing to improve between now and 2020.  I know some people have pl=
ans=20
they're already working on.

Conceptually, as Nicolas and you have both hinted at, PHP 7.x is the series=
=20
where "typing got real".  From a user-facing/marketing perspective 7.x is a=
ll=20
about performance and typing.  That's the through line.  Including typed=20
properties in that makes logical sense, marketing-wise, and would be a fitt=
ing=20
capstone to the 7.x series in that regard. =20

That's true regardless of whether typed properties go into 7.3 or 7.4; if=20
given the timing they need to wait for 7.4 to have some extra polish done=20
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=20
need a big showy thing in 8.0 to help sell it", er, feels like a=20
contradiction.  It makes it sound more like "borrowing" a feature from 7.3=
=20
(typed properties) for 8.0 for purely marketing purposes, and then also=20
blocking any other features, so that we know 2 years out "the only interest=
ing=20
thing in 8.x will be typed properties, because that was written when 8.x wa=
s=20
still just a twinkle in the eye but we sat on it".  That feels very=20
disingenuous.

I am sure that's not your intent but those two statements together ("minimi=
ze=20
features for 8.0" and "save this feature for 8.0 for marketing") just don't=
=20
fit together in my mind in a nice way.

=2D-Larry Garfield
--nextPart19634238.YjFZB9JIL8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE/ph/GXfY8v0YwFBp4MMKwDFxYXcFAltFBnwACgkQ4MMKwDFx
YXcgQAgAiV8TvMjjPpg6vceWqax4fMkXeMlDV1a6oGEXpBQTv3QpoEiDjFSCB6dD
slxytVK1XboDxpKM+j+HTRgqp+DecridZMfneV4xWF0tLHWdyk/FA7C7YlKw1c69
0cG8Tydfjf+8Z58NOwwGqrHM4ngHumwwonqbm+MGFYghNSxiXf6MQuCAT8/Mkpdr
yHrTkNre8HsMNOdVTsHDcyGKFgfbsWdj2QSy7peRClRmlZQCOTauBZwVdrJETqmi
DAvslxvdL/j9kWePC9Z/c4uOZkHk86r6Nzp/qiiMWgSXU29Jd19JahLOLex7jE1W
nG6iEC0UdvvAOnQ0WAZYFfvcILv6jw==
=hyjs
-----END PGP SIGNATURE-----

--nextPart19634238.YjFZB9JIL8--