Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107006
MIME-Version: 1.0
References: <076701d56978$86020910$92061b30$@php.net> <CAKuGYLQA+XMHLGXPM4n_eEdp-d1=WzDE4Z4iLOzhD+4m83McaQ@mail.gmail.com>
 <467be4a0-dd8b-29d2-0b09-a3efd7fad56a@heigl.org> <CAJHtznwJLryZa1fWHXUJd5OS+9YKBjAj30fpN7sjR3By7a-DbQ@mail.gmail.com>
In-Reply-To: <CAJHtznwJLryZa1fWHXUJd5OS+9YKBjAj30fpN7sjR3By7a-DbQ@mail.gmail.com>
Date: Thu, 12 Sep 2019 20:51:19 +0200
Message-ID: <CAAfnsFU8B7gpd1=CpO+eDr7ogqDdFX7pZYNTT9rSoTDz+ybUQw@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Andreas Heigl <andreas@heigl.org>, Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: peterkokot@gmail.com (Peter Kokot)

On Thu, 12 Sep 2019 at 20:35, Zeev Suraski <zeev@php.net> wrote:
>
> On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andreas@heigl.org> wrote:
>
> >
> >
> > > You may be wondering, in that case, what processes do we have to deal
> > with
> > > such changes then?  The answer is simple.  We don't.  We don't have to
> > have
> > > them either - the fundamental language behaviors are here to stay.
> >
> > But we still need processes to define which are the "fundamental
> > language behaviours". And as change is the only constant in
> > software-development, these "fundamental language behaviours" might, can
> > and probably should be changeable. I'm not saying they need to change,
> > but it has to be possible to change them. Otherwise we would still
> > program business-logic in C as that was Rasmus' fundamental idea IIRC
> > (Correct me if I'm wrong)
> >
>
> You're right.  The thing is this - as I said, the RFC process was designed
> to address additions to the language - as is implied in numerous places
> (both the part I quoted from the RFC itself, as well as elements in RFC
> template as well as the RFC howto).  It was never meant to handle
> deprecations - mainly because we simply weren't doing much of that back in
> the days where it was introduced.  It was meant to resolve the issue at
> hand at the time (and in the years leading up to it) - which is a formal
> way to agree on which features make it in and which ones don't.
> Now, over the years (and more and more as of late) - it started being used
> for deprecations.  But these deprecations have become more and more extreme
> recently in terms of their impact.  Of course I do think deprecations
> should be allowed, like in any other language.  I do think we need to have
> a higher bar for them in general (both in terms of a clear benefits and
> required majority - as is implied in the Voting RFC) - but since we've
> grown used to using 2/3 for them - and given the pro-deprecation bias of
> the current composition of internals@ - I also realize it will be tough to
> do.  But when dealing with deprecation proposals that are likely to effect
> a very sizable subset of our userbase and codebase, and deal with some of
> the most basic building blocks of the language - we simply can't start
> using the same process.  We never have in the past (none of the
> deprecations we voted on since 2013 comes even remotely close to the level
> of impact of the two proposals that have been put forward to a vote in the
> recent couple of months, and the more recent one clearly far outdoes the
> prior one in terms of impact).
>
> Should we have 'woken up' many years ago when we started using the Voting
> RFC for deprecations it wasn't meant to handle?  Probably.  It would have
> been much easier to install a new mechanism.  But it doesn't mean we should
> repeat the same mistake, now that it begins to be used to deprecate
> mainstream language behaviors.
>
> In terms of telling one from the other - right now, I'm afraid it's a bit
> like some other things that fall into the category of 'you know it when you
> see it'.  I think few can deny that far-reaching effect of changing how
> variables behave in a language, whether they think it's a change for the
> better or for the worse.  But I think it *may* be possible to formally
> define.  These are just random thoughts at this point - but we could have a
> set of apps/frameworks that we use as a testing bed to check the level of
> impact of a certain proposal.  If that impact is above a certain threshold
> - it will be considered fundamental.  Of course, things like WordPress,
> Joomla and MediaWiki would have to be a part of that - not just modern
> frameworks.  It's still not ideal since it doesn't account for the majority
> of PHP code out there which isn't Open Source - but it may be a start.
> There may be other ways - such as letting folks run that analysis on their
> own code behind the firewall and report results back.
>
> But there's also a simpler solution to this.  This 'can of worms' as Arvids
> called it, wouldn't have been opened had we agreed to focus on extending
> PHP instead of trying to replace it with something else.  This is what the
> RFC process was meant to facilitate.  It still can, but for that, we need
> to change the dynamics from a zero-sum game to a goal of a win/win.  Yes, I
> realize that I'm sounding like a broken record.  But call me naive - I'm
> still hoping that given it obviously can be done from a technical
> perspective (in a wide variety of ways too) - we can find the good will to
> do it from a human perspective.
>
> Zeev
>
>
> >

Just a dumb idea, since there clearly is a majority in favor of the
change with these warnings and strictness and all that now... Why not
making something like an LTS PHP 7.x where all the legacy code would
work OK as long as practically possible and 8.x+ would be the future
of what the developers want and not what business wants? One who won't
upgrade due to the BC breaks also won't need the new features anyway
very realistically.

Microsoft, Zend, and Red Hat have been showing that this is actually
possible. How smart this is for the PHP progress is another story, but
for the business it might be good to think about this also I guess:
https://github.com/microsoft/php-src/releases

So, to make some sort of a milestone with some of the versions -
either 8 or 9 or something.


-- 
Peter Kokot