go to bug id or search bugs for
When you check if private/protected constant is defined on a class, it currently triggers a fatal error.
For a consistency with method_exists and property_exists it should probably ignore visibility and return true
private const BAR = 1;
Fatal error: Uncaught Error: Cannot access private const Foo::BAR
Add a Patch
Add a Pull Request
it should return false but not raise a fatal error at all, but there is no valid reason to return true because you can't access it outside the class
The reason (as I said in the bug report) is a consistency with property_exists and method_exists, see https://3v4l.org/7PYOQ
you still compare different things here and for consistency they all should return false outside of the context $this because it's simply wrong behavior leading to errors like this one which couldn't work beause for the current scope it don't exist
$foo->bar = 10;
$foo = new Foo;
I agree with you it would be better if a current scope were taken into account for all three methods.
But you can even see in a changelog of property_exists
( http://cz2.php.net/manual/en/function.property-exists.php ) that "This function checks the existence of a property independent of accessibility." So I suppose there was some good reason for this behavior and therefore I think "defined" function should behave in the same way.
I believe the closer analogon to defined() on constants is isset() on properties and is_callable() on methods, both of which will take visibility into account. property_exists() and method_exists() are more like reflection methods, from a time where reflection didn't exist yet.
@firstname.lastname@example.org: but in no case it has to raise a exception / fatal error because such things are typically used to test if something exists instead blindly call it and then fail - so the current behavior defeats the whole purpose
Yes, obviously. My comment was referring to the discussion whether the return value should be true or false for an inaccessible class constant.