[RFC] Throw Exception on Attempt of Constant Redefinition

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:

<?php
const Foo = 1;

class FooFactory {
static function make() {
return Foo;
}
}
?>

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?

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/

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

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.

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

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.

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.commailto:smalyshev@gmail.com> wrote:

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

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]