Support Mixins(?)
See original GitHub issueHey @juanchosaravia, I’d like to apply @AutoDsl
on classes contained within a separate Gradle/Maven module or dependency, i.e. not in the current source.
Is something this in the roadmap? Should i try patching up a PR?
For the latter please note i’ll probably have to:
- Add an
@AutoDslMixin
annotation - Add a dependency to my kotlin-utils’ kapt module
The implementation would allow something like:
@AutoDslMixin(
dslName = "whatever", // Default: "person"
dslSource = Person::class)
class PersonMixin
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
mixin and @include - Sass
Mixins allow you to define styles that can be re-used throughout your stylesheet. They make it easy to avoid using non-semantic classes like...
Read more >Documentation - Mixins - TypeScript
TypeScript's best mixin support is done via the class expression pattern. You can read more about how this pattern works in JavaScript here....
Read more >Mixins - The Modern JavaScript Tutorial
JavaScript does not support multiple inheritance, but mixins can be implemented by copying methods into prototype. We can use mixins as a way...
Read more >Sass @mixin and @include - W3Schools
The @mixin directive lets you create CSS code that is to be reused throughout the website. The @include directive is created to let...
Read more >Mixin - Wikipedia
In object-oriented programming languages, a mixin (or mix-in) is a class that contains ... or to work around lack of support for multiple...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Had a couple of issues with that approach:
@AutoDsl
there only works if the target class is open, while it doesn’t produce the target type anyway. Also a bit problematic in case of data classes.AutoDslCollection
)I’m concern of the need to create new classes to generate builders for other classes. Seems to be a lot of code just to provide support to external class that should not really be exposed in a DSL. You could easily create a class to encapsulate the internal classes that you use or any class from any library. In that case you will not need to expose that class with your DSL and then no need to apply AutoDsl to that internal class.