Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107009
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 15:06:03 -0400
Message-ID: <CAPKYkKy=-U=pE-fBw0EP0A8D--gJfyy+f=Uz3ihjGTAJ5G7Oyw@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Andreas Heigl <andreas@heigl.org>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e3da8405925fd4e3"
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000e3da8405925fd4e3
Content-Type: text/plain; charset="UTF-8"

On Thu, Sep 12, 2019 at 2:35 PM 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.
>
>
Exactly. I think it's telling that the majority of the rebuttals to
arguments against the RFC are to claim that we're against moving the
language forward, against BC breaks, etc. That couldn't be further from the
truth. We do want to move the language forward. We want do that by adding
to the language, and not changing it into an entirely different language.


> Zeev
>
>
> >
>


-- 
Chase Peeler
chasepeeler@gmail.com

--000000000000e3da8405925fd4e3--