Why_not_move___Compose_to_language_level__as_you_a...

# compose

[Arman Chatikayn]

Why_not_move___Compose_to_language_level__as_you_already_do_some_byte_code_changes_with_compiler_plugin__I_mean_maybe_something_like_this_will_be_better_.kt

Why_not_move___Compose_to_language_level__as_you_already_do_some_byte_code_changes_with_compiler_plugin__I_mean_maybe_something_like_this_will_be_better_.kt

[Fudge]

I would say because adding a language feature requires a lot of work, careful planning and bierocracy bureaucracy XD, and having it as an annotation is just fine for the uses of a single domain.

[simon.vergauwen]

It's a compiler plugin. In some other languages those can create first class language support.

[simon.vergauwen]

@Arman Chatikayn AFAIK Kotlin compiler plugins cannot add keywords

[streetsofboston]

bierocracy

Love that word 🍻
😆

[louis993546]

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1558563482240100?thread_ts=1558438937.115600&cid=CJLTWPH7S

[miha-x64]

compose fun doesn't mean anything. Functions are already composable building blocks, there's nothing you can add here.
While @Compose fun screams at you: 'SOME BAD CODE RIGHT HERE! There's some reflection/codegen/transformations because abstractions are done wrong!'
Thus, annotation is significantly better here.

[Ryan Mentley]

For reference, there's no reflection involved in the @Composable annotation. There are codegen/transformations though.

[miha-x64]

I know. But ideologically it is the same thing: implicitness and indirection.

[Tristan Caron]

On React for Kt, they use fun RBuilder.button(). Something like Composable.Button() might have been considered, but I am not sure if it works well for codegen. I guess the compiler is doing some optimizations and create some template functions like Ivy (Angular).

Will the IDE be able to know that we are in a @Composable or not, and allow or disallow some code?

[miha-x64]

Well, maybe no, as Android Studio (IDEA plugin) looks abandoned.

[SrSouza]

@Tristan Caron I think that just extension function not work for Compose, the annotation generates much more things that just a new argument in a function.

You can read this blog post from Leland Richardson to understand compose from the first principles
http://intelligiblebabble.com/compose-from-first-principles/

[Ryan Mentley]

Will the IDE be able to know that we are in a @Composable or not, and allow or disallow some code?

Yes, this already mostly works. You can't call composable functions from outside a composable function.

[Ryan Mentley]

Something like Composable.Button() might have been considered

It was indeed. There's some discussion here:
https://kotlinlang.slack.com/archives/CJLTWPH7S/p1558458471177900?thread_ts=1558440714.121300&cid=CJLTWPH7S

[Tristan Caron]

Would it be fair to compare @Composable with something like #[derive(Composable)]? https://doc.rust-lang.org/1.15.1/book/procedural-macros.html So, maybe instead of introducing a new keyword just for compose, maybe it could be interesting to make codegen something integrated to Kotlin compiler. I don’t really know how it works today, but my guess is, if we want to use code generation, we have use an external lib, and run something like gradle codegen as much as it’s necessary. But for compose, it’s doing codegen on its own, and we have to use a plugin to ensure a good development experience.

[pavi2410]

Why bring so much complexity? In my opinion, general purpose programming languages like Kotlin shouldn't bend to a framework's needs.

[Ryan Mentley]

In a way, it is integrated with the Kotlin compiler - it's a compiler plugin. So there's no need for separate tasks - you just compile your code like you normally would and it works.

[dewildte]

Kotlin does not bend it’s knee to the framework, there should be no argument around this.