This will break backwards compatibility, as you could use them in a child implementation and overwrite them. @csarrazi do you know if that was intentional?

This is, but it's a design fix too. Const override is really not a good practice, and const must not be part of the interface.

It's a BC break nevertheless. The question is whether this is ever used, but we can't check that. Perhaps on initialization of the object you can do something like this?

public function __construct(...)
{
    if (static::DEREF_NEVER !== QueryInterface::DEREF_NEVER) {
        @trigger_error('...', E_USER_DEPRECATED);
    }
}

@iltar I can not make it deprecated and fixed it in the same time. But i dont think this is ever used.

You can trigger the deprecation, which should cause developers to fix the issue. It'll have to be fixed in 5.0. It's up to the core members to decide whether or not this is an acceptable BC break

Actually, one of the things I'm unsatisfied with is the fact that the values in QueryInterface are actually extracted from the ext_ldap implementation, which is actually problematic as this means that the implementation leaks into the interface.

This was actually the rationale behind using static:: instead of QueryInterface, as the goal was that other implementations could use other values.

For 5.x, the actual values used in the QueryInterface should instead be defined in the actual implementation instead of the interface, and the interface constants should rather be string values.

I'm personally not a fan of having constants in an interface, because it spreads to every implementation. Would it be an idea to make a final class with private constructor to limit the constants to 1 class instead?

I agree. We should create a LdapOption, which would contain string values for each constant.
The actual value (used by ext_ldap) should be limited to the actual implementation, so should only be present in the query implementation.

please revert this change, it's unrelated and not needed

"isset" would do it