Fluent API does not use own Assertion class about assert

[m3co-code]

+1

[frankdejonge]

This is not going to work without a class alias or a globally set assertion class. Both are not really ideal. These function are namespace bound and internal code relying on either one of the solutions leads to code smell. I'd say, want to use the functions? Either use the default implementation or cop the functions into the namespace that your own implementation resides in. Some things would have to be altered, like the hardcoded FQCN in AssertionChain in order for that to work.

Another option would be to replace the functions with public static methods, these are basically fancy alternative constructors and don't create state, which doesn't introduce anything into the global scope.

[sagikazarmark]

I can imagine a solution like this:

\Assert\withCustom('CustomAssertionClass')
    ->that(null)
    ->notNull();

[bicpi]

+1 I'd also like to use my own exception class in a clean way when switching to the fluent interface.

[Solinx]

+1

[gries]

👍

[acgrid]

It headaches me too.
I forked it with my implementation here https://github.com/acgrid/assert which everything can be inherited and work with each other.
The significant issue to me is helper functions, I added two getter/setter functions to provide an interface to access which class to be used.
To make it production usable, I made the fork namespaced (avoid possible collusion with another composer component) and tagged version x.1.
Since the change would be BC-breaking, so I am not confident to PR.

[tacovandenbroek]

This issue should be solved as of release 2.6.7