# [RFC] Throw Exception on Attempt of Constant Redefinition - Thread: https://externals.io/message/93885 - Original archive: https://news-web.php.net/php.internals/93885 - Started by Dmitry Stogov on 2016-06-10T20:06:55+00:00 - Messages: 14 - RFC: Exception on constant redefintion (Inactive) — https://externals.io/rfc/constant_redefinition.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #93885 — Dmitry Stogov — 2016-06-10T20:06:55+00:00 URL: https://externals.io/message/93885#93885 Hi internals, Please review: https://wiki.php.net/rfc/constant_redefinition Thanks. Dmitry. --- ## #93887 — Levi Morrison — 2016-06-10T20:50:26+00:00 URL: https://externals.io/message/93885#93887 · In reply to: #93885 > Hi internals, > > > Please review: https://wiki.php.net/rfc/constant_redefinition > > > Thanks. Dmitry. Dmitry, I am not sure this change will actually allow constant propagation either. Consider this code: In this series of events: - Foo is declared to be 0 - This above file is now included inside a try-catch block that catches the error - FooFactory::make() is now called If Foo = 1 was propagated then FooFactory::make() will return 1 instead of 0. Am I missing something? --- ## #93890 — Dmitry Stogov — 2016-06-10T21:27:29+00:00 URL: https://externals.io/message/93885#93890 In general, you are right, but this is possible only if application ignores Error exceptions... --- ## #93895 — Xinchen Hui — 2016-06-11T07:48:36+00:00 URL: https://externals.io/message/93885#93895 · In reply to: #93885 Hey: > Hi internals, > > > Please review: https://wiki.php.net/rfc/constant_redefinition we could also change the #define DEFAULT_OPTIMIZATION_LEVEL "0x7FFFBFFF" (introduced in https://github.com/php/php-src/commit/40702799b5f08b093477098881b6e0cfcb3ea411 ) to -1 I think it's better also include this into the patch? thanks > > > Thanks. Dmitry. > -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #93898 — Fleshgrinder — 2016-06-11T15:01:11+00:00 URL: https://externals.io/message/93885#93898 · In reply to: #93885 > Hi internals, > > > Please review: https://wiki.php.net/rfc/constant_redefinition > > > Thanks. Dmitry. > This would be a breaking change in a minor release again. -1 However +1 for PHP 8. -- Richard "Fleshgrinder" Fussenegger --- ## #93931 — Christoph Becker — 2016-06-13T11:37:01+00:00 URL: https://externals.io/message/93885#93931 · In reply to: #93898 > > > […] > > This would be a breaking change in a minor release again. > > -1 > > However +1 for PHP 8. I'm also somewhat concerned with regard to turning a notice into an exception in a minor version. I would prefer to have an alternative voting option to deprecate constant redefinition in 7.1 and to finally disallow it in 8.0. It might be helpful to make a rough plan when PHP 8.0 will be released. If that will be far in the future (say 5 years or even more), such a change might be okay for a minor version (presumably nobody wants to wait such a long time for this and similar improvements), but if PHP 8.0 will be released much earlier, it might be tolerable to wait and to not break semantic versioning. -- Christoph M. Becker --- ## #94039 — Dmitry Stogov — 2016-06-16T06:44:00+00:00 URL: https://externals.io/message/93885#94039 · In reply to: #93885 The voting dates was changed to Jun 24 (to satisfy 2 weeks discussion period). In my opinion the BC break is minimal. Actually, the "wrong" behavior was reported by https://bugs.php.net/bug.php?id=71127 Before this, opcache worked "improperly" for few years (at least since php-5.4). Unfortunately, we fixed https://bugs.php.net/bug.php?id=71127 too later and weren't able to fix PHP-7.0 "properly". Now I propose a safer and more consistent way of handling attempts of constants redefinition. RFC also proposes a way to "fix" affected applications, wrapping constant definitions, that may be redefined, with try/catch. Thanks. Dmitry. --- ## #94040 — Pierre Joye — 2016-06-16T08:17:43+00:00 URL: https://externals.io/message/93885#94040 · In reply to: #93890 > > In general, you are right, but this is possible only if application ignores Error exceptions... Exactly. Many if not hundred of applications do not even use exception but if a couple of places, let alone plug-ins for these apps. Most of these apps is what I called main stream applications. They are provided as SaaS or ready to be installed. The providers taking care of the system parts, php included. Now what will happen if they update and exception start to be throw for that? Right, they will downgrade or not update at all for the good ones (tested). To me it sounds like a pretty bad plan to ease the migration path. In other words, it looks to me that you are working on something bigger, early phase. This things seems to require more and more clean paths and rules. This is alone is something to justify to start to plan 8. And we all know Jit will be for 8. Let start even if the Jit itself is not even officially started. --- ## #94042 — Lester Caine — 2016-06-16T09:04:59+00:00 URL: https://externals.io/message/93885#94042 · In reply to: #94039 > RFC also proposes a way to "fix" affected applications, wrapping constant definitions, that may be redefined, with try/catch. Doesn't anybody remember the problems which STILL have to be resolved with changes in PHP5.2/3/4 which require the assistance of programmers to fix naive users problems. Now many of the new features being added will not be currently used in legacy code, but can anybody ensure that all of the BC changes being currently pushed for will not cause a more general PHP5.4 style block to upgrading? HAVING to add changes to code to retain a legacy style of operation is something that should only happen in a major version. Isn't this why most big projects no longer bother with many small version changes? What is Firefox up to now ... However going down that root does require LTS builds which is something else which is maintaining PHP5.3 in the field. I am now getting used to the changes in PHP7, but the current roadmap for PHP7.1 is just another PHP5.4 in my book and it does create a case for my simply rolling back to PHP5 since none of my production systems have been fully updated so they can use PHP7 yet ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #94048 — Stanislav Malyshev — 2016-06-16T17:14:13+00:00 URL: https://externals.io/message/93885#94048 · In reply to: #93885 Hi! > Please review: https://wiki.php.net/rfc/constant_redefinition I would propose to not throw an error if constant is redefined to exactly the same value. Some of the code might be doing this unknowingly, e.g. by writing include instead of include_once, and there's no real reason to break it. -- Stas Malyshev smalyshev@gmail.com --- ## #94065 — Dmitry Stogov — 2016-06-17T06:10:39+00:00 URL: https://externals.io/message/93885#94065 Got it :( Then this may be a serious BC break, and it's better to depricate it in 7.1 and throw exception only in 8. Thanks. Dmitry. Hi! > Please review: https://wiki.php.net/rfc/constant_redefinition I would propose to not throw an error if constant is redefined to exactly the same value. Some of the code might be doing this unknowingly, e.g. by writing include instead of include_once, and there's no real reason to break it. -- Stas Malyshev smalyshev@gmail.com --- ## #94066 — Pierre Joye — 2016-06-17T06:31:33+00:00 URL: https://externals.io/message/93885#94066 · In reply to: #94065 > > Got it :( > Then this may be a serious BC break, and it's better to depricate it in 7.1 and throw exception only in 8. Fully agree. Thanks :) > Thanks. Dmitry. > > > > On Thu, Jun 16, 2016 at 8:14 PM +0300, "Stanislav Malyshev" < smalyshev@gmail.com> wrote: > > Hi! > > > […] > > I would propose to not throw an error if constant is redefined to > exactly the same value. Some of the code might be doing this > unknowingly, e.g. by writing include instead of include_once, and > there's no real reason to break it. > > -- > Stas Malyshev > smalyshev@gmail.com --- ## #94162 — Dmitry Stogov — 2016-06-20T20:42:43+00:00 URL: https://externals.io/message/93885#94162 The RFC was updated to propose this change only for PHP 8.0, and thereby, vote is delayed for uncertain time. I think, changing "Notice: Constant %s already defined" into "Deprecated: ..." in 7.1 doesn't make a lot of sense. Thanks. Dmitry. --- ## #94164 — Rowan Collins — 2016-06-20T22:08:35+00:00 URL: https://externals.io/message/93885#94164 · In reply to: #94162 >The RFC was updated to propose this change only for PHP 8.0, and >thereby, vote is delayed for uncertain time. Why can't we have a vote now, committing to a change in 8.0? Doing so would have two advantages: - Users have extra advantage warning of the change. Even if the message doesn't change, the documentation could include a warning, and people could spread the word - Long-term engine developments could proceed in the safe assumption that the change will be accepted, rather than having to consider the possibility of a future vote forcing a backtrack. As I've said elsewhere, the only reason we don't have any plans for 8.0 is because we're not making any plans for 8.0; we can start doing that whenever we like, and using whatever process we like. Targeting a few votes and listing them somewhere seems as good a place to start as any. Regards, -- Rowan Collins [IMSoP]