-
Notifications
You must be signed in to change notification settings - Fork 4
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
Add spec method to Exact #20
Conversation
I don't really see the benefit for this. It makes the DSL more verbose, and adds limitations (e.g. the companion object cannot extend any other class) for no reason I see. Personally, I'd prefer keeping it as it is now, or letting the user decide (e.g. have a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it! Thank you @ustits 👍
@CLOVIS-AI I thought the same at first but the benefit is that your IDE will generate the majority of the code and also it's more obvious than companion object by ...
.
@CLOVIS-AI @ILIYANGERMANOV Actually I figured out how we can keep both approaches. I turned Exact back to interface and since it is a functional interface we can instantiate it like this: @JvmInline
value class NotBlankString private constructor(val value: String) {
companion object : Exact<String, NotBlankString> by Exact({
ensure(it.isNotBlank()) { ExactError("Cannot be blank.") }
NotBlankString(it)
})
} @nomisRev I will need help, I added one more example to |
Oh, that's great. This way, we can explain to users how it works using the regular interface implementation using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nomisRev I will need help, I added one more example to Exact but the last one is not showing in documentation in IDE, can't understand why
@ustits I think this has been resolved in 0348de6?
Amazing work all! I cannot believe how incredible this DSL looks, and the underlying code is really simple 🙌
Thanks all for collaborating so amazingly 😍
Co-authored-by: Simon Vergauwen <nomisRev@users.noreply.github.com>
@nomisRev thanks for the feedback! Actually the problem was in using |
ChangedAddExact
to abstract class instead of interfacespec
function inExactEither
with context ofRaise
so that clients can both use implementation and implementation by delegationI suggest that developers won't need to implement/extend their companion objects in most scenarios, so that restriction won't be a big problemExtending from abstract classImplementing feels more "natural" than delegating usingby
and I think it will be more convenient for clients. But let's keep delegation is a viable alternativeExactScope
in favour of extendingRaise
ExactDsl
, I will agree with @CLOVIS-AI in Replace ExactDsl by RaiseDsl #15, adding a separate dsl marker for methods with same semantics will look confusing for clients of library