Hey there, first of all thank you for open sourcing this library. It's a very original solution to the problem and the (appalling) lack of support for something so basic as mandatory dependencies in DSLs.
Just like you I have tried everything with contracts and it all was extremely verbose and error-prone. Not to mention what happens when you start adding generics to the components you need to build through the DSLs. Type inference and contracts aren't really ready for that.
Just have a question for now: was it a deliberate choice to not enable the Linter checks in unit tests?
I was initially testing an implementation of a @DSLint interface in a unit test and I only realised the errors are highlighted in production code only.
Also, I've noticed that compilation for a (library) module doesn't fail when there's a DSL error. Is there a way to enable that?
Hey there, first of all thank you for open sourcing this library. It's a very original solution to the problem and the (appalling) lack of support for something so basic as mandatory dependencies in DSLs.
Just like you I have tried everything with contracts and it all was extremely verbose and error-prone. Not to mention what happens when you start adding generics to the components you need to build through the DSLs. Type inference and contracts aren't really ready for that.
Just have a question for now: was it a deliberate choice to not enable the Linter checks in unit tests?
I was initially testing an implementation of a
@DSLintinterface in a unit test and I only realised the errors are highlighted in production code only.Also, I've noticed that compilation for a (library) module doesn't fail when there's a DSL error. Is there a way to enable that?