This looks interesting. <http://manifold.systems/>

# random

[thomasnield]

This looks interesting. http://manifold.systems/

[dalexander]

Seems kind of neat. I’m curious how it actually works.

[thomasnield]

Yeah the extension functions seem pointless, but the data structure stuff... I almost want a Kotlin plugin to do something like this. Would be enormously handy for data exploration.

[robin]

Yeah the Type Manifolds look awesome, wondering how seamless it actually works in practice. Extension Classes, meh, already got that in Kotlin. Structural interfaces look interesting, not sure I really see the use case though.

[robin]

@dalexander Seems like manifest provides a plugin to the Java Compiler that knows how to compile the additional features. Interesting approach, I'd like to see how it compares performance-wise

[thomasnield]

To have a Kotlin plugin that reads a SQL, text file, or JSON data source and automatically structures types off them... that would be huge especially for data science-y workflows.

[dalexander]

Does sound like it would be useful. Couldn’t we use manifold for that and access it’s output from Kotlin (at least to prototype?)

[dalexander]

Although to be honest the things that seemed most useful from the plugin (for my needs) were the type enhancements.

[dalexander]

Ohhh… If the javac ecosystem allows plugins like this, I wonder if it would change what is on the table for Kotlin language design (since they could write a javac plugin to support Kotlin features that would otherwise potentially be problematic).

[robin]

Plugins for javac won't do anything for kotlin, as kotlinc already completely bypasses javac and compiles to bytecode directly, so even with plugins javac can't do anything kotlinc couldn't already be built to do.

[dalexander]

No… It’s for improving compatibility of Java code with what kotlinc generates. There is frequently the question “You want to add this feature to Kotlin, so how does it interoperate with Java”? If there were a kotlin plugin for javac it could be an answer to some of those questions. So for a simple example it could make the fields of companion objects transparent to access from Java without @JvmStatic

[robin]

Ah, gotcha. That might work for mixed codebases, but would do nothing for library creators because they don't have control over whether client code is compiled with the necessary plugin, so to be as useful as possible they still need the additional overhead. And just for those mixed codebases it's not really worth it, imo, since mixed codebases that actually plan to suspend polyglot development for longer than an initial transition phase are probably quite rare.