Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fluent API does not use own Assertion class #57

Closed
dmolineus opened this issue Jun 5, 2014 · 8 comments
Closed

Fluent API does not use own Assertion class #57

dmolineus opened this issue Jun 5, 2014 · 8 comments

Comments

@dmolineus
Copy link

There is no way to use a specific Assertion class when using the fluent api. So using fluent api andd an own excpetion type at the same time have a drawback to me. When changing the assertion a differnt exception will be thrown.

try {
    \My\Custom\Assertion::notNull(null);
    // throws \My\Custom\Assertion::$exceptionClass

    \Assert\that(null)->notNull();
    // throws \Assert\Assertion::$exceptionClass
}
catch(\My\Custom\AssertionFailedException $e) {
    // ...
}
@m3co-code
Copy link

+1

@frankdejonge
Copy link

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
Copy link

I can imagine a solution like this:

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

@bicpi
Copy link
Contributor

bicpi commented Feb 29, 2016

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

@Solinx
Copy link

Solinx commented Feb 29, 2016

+1

1 similar comment
@gries
Copy link

gries commented Jun 9, 2016

👍

@acgrid
Copy link

acgrid commented Oct 18, 2016

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
Copy link
Contributor

This issue should be solved as of release 2.6.7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants