Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107005
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=f4cGVDx7yfqKlPOsXojx4J1pg40xOyYeo2eHNmaaprq+kRSvK+wxx9q7tYGNyv
	vbIzVR8oNbyBVzLn7lr71x7mnbmoW4xEVvgdSM9mgpV/LC+YYZljWpnsh92mAEWg
	KyhfKKHTsrOMzbKmBW77CEwFFrLQuAB+1FGtc6XfP07Wc=;
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>
In-Reply-To: <467be4a0-dd8b-29d2-0b09-a3efd7fad56a@heigl.org>
Date: Thu, 12 Sep 2019 21:35:09 +0300
Message-ID: <CAJHtznwJLryZa1fWHXUJd5OS+9YKBjAj30fpN7sjR3By7a-DbQ@mail.gmail.com>
To: Andreas Heigl <andreas@heigl.org>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006b540505925f6687"
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: zeev@php.net (Zeev Suraski)

--0000000000006b540505925f6687
Content-Type: text/plain; charset="UTF-8"

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


>

--0000000000006b540505925f6687--