On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl <andr...@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 >
