Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102706
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.49 as permitted sender)
MIME-Version: 1.0
References: <CAF+90c_L7S+EB8YxdNNpNZ7NhhYwCbwEw5_TSnSwUNN-zLVvCg@mail.gmail.com>
 <b4a9394a-184f-906a-0e34-c14cf8172666@gmail.com> <CA+kxMuQk_5KJT5RPK6B2+4whS1Wz4NTxLDAhXkc0uSurxPNLPw@mail.gmail.com>
 <CAESVnVrFsZCEbwTTs+ROF19nHh6=XN6dhHJqxVw5EKa5bK5ngA@mail.gmail.com>
 <c2b3a7b2-b4b6-db88-a7c7-5a08fed0d8a4@telia.com> <CAF+90c8tNO1SsMjGnW9tGPGHtY4kD07SNS-qC_LfkVXVsp0GUA@mail.gmail.com>
 <10e578d7-7a24-3ca0-ca0d-d5ed1a39dca3@telia.com> <80a8f588-05a3-48e5-bf40-bf1685b3105e@gmx.de>
 <CAF+90c-gOKrnHtLv1oJuHQ9QWxYjEZHwAzzaUL0c18x48=HezQ@mail.gmail.com>
 <bd79bc16-ff3d-1c9b-a775-9c50c422b8a2@gmx.de> <CAESVnVpHhKPBsTQgu=4u3UPC1oF_e6-iW9_njbq+09WTQb+Oqw@mail.gmail.com>
 <CAESVnVogxMdbdObdS2Kz-+WP5U=+VvzVXfr55Qy6iYNg=2Z-Wg@mail.gmail.com>
 <DM5PR0201MB35423A128EDAFE866C73B66EAC460@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <D197D623-17A5-4EB3-A578-93BF860AD68E@ez.no> <CADyq6sJDo_4jBx3dZ6eR7mS29-aEB7Ky3eta9st2VQDra23crA@mail.gmail.com>
 <CAOWwgpkC+-jvwN5VQwuvf6726e6cG4TD7hPpFcbKmtOXT7671w@mail.gmail.com>
 <CAJHtznxasnJE4mDsg7DYPBQZBCMkAKGafqj5MEMHMp03ye=RuQ@mail.gmail.com>
 <CAJd4=YYTP0caBhQda1HheiamHPtvO2XqXN4R=DgWF1iMdC7DeQ@mail.gmail.com> <CAJHtznybD1L5MnzhcNB_Kb0UPgag3zbrpOtr5zbfWCehx++R6w@mail.gmail.com>
In-Reply-To: <CAJHtznybD1L5MnzhcNB_Kb0UPgag3zbrpOtr5zbfWCehx++R6w@mail.gmail.com>
Date: Tue, 10 Jul 2018 15:18:29 +0300
Message-ID: <CAOWwgpkYbP_SMSde+kbTQtJNfYY-EE05yMMnx2+Ms8Cp5_aXYw@mail.gmail.com>
To: Zeev Suraski <vsuraski@gmail.com>
Cc: mail@pmmaga.net, Marco Pivetta <ocramius@gmail.com>, =?UTF-8?B?QW5kcsOpIFIu?= <andre.romcke@ez.no>, 
	Zeev Suraski <zeev@zend.com>, Sara Golemon <pollita@php.net>, 
	PHP Internals List <internals@lists.php.net>, nicolas.grekas@symfony.com
Content-Type: multipart/alternative; boundary="000000000000b6603b0570a4214f"
Subject: Re: [PHP-DEV] [RFC] Typed Properties
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000b6603b0570a4214f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le mar. 10 juil. 2018 =C3=A0 14:56, Zeev Suraski <vsuraski@gmail.com> a =C3=
=A9crit :

> On Tue, Jul 10, 2018 at 2:06 PM Pedro Magalh=C3=A3es <mail@pmmaga.net> wr=
ote:
>
>> On Tue, Jul 10, 2018 at 11:33 AM Zeev Suraski <vsuraski@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 yea=
rs
>>> even) in order for it to be included in a major version, and not a mino=
r
>>> one (phpng, JIT, FFI) even though technically they could go into the ne=
xt
>>> 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 positi=
ve
> 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 a=
s
> major - getting people more motivated to upgrade, bring positive vibes an=
d
> attention around the language, etc. (as was the case with 7.0) - since th=
e
> 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 rea=
l
> - 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 matte=
r
> - scalar type hints?  Both of these (performance boosts and scalar type
> hints) could easily go into 5.7 from a purely technical perspective.
>
> Zeev
>


Just to clarify my previous statement: marketing is a good reason to bump a
major version. Doing so creates momentum after the release and motivation
before.

I just don't agree that typed properties are part of that. They are a
really natural and important feature, but not one that will allow anyone to
do anything new that wasn't possible before.
JIT and/or async are game changers. They don't play in the same category to
me.
Others might disagree of course, and I don't want to minimize their
importance nor the work of Nikita and Bob. Kudos to them actually.

Nicolas

>

--000000000000b6603b0570a4214f--