We are currently having warmed up discussion in Russian chat and there are different opinions on that. Most android developers are happy. But I was not developing on android for a long time and for me syntax looks terrible. Why function calls with capital letter? Why do not use explicit receivers for composable functions? Currently it looks like a lot of classes with side-effects in constructors. There are existing frameworks like tornadofx. Why not to do something similar?

Those were exactly our thoughts, I remember reading somewhere (a thread in #compose IIRC) they did it to avoid people getting confused but I think they are just doing the opposite

I think that they tried to clone Flutter grammar. I really hope, that there will be normal kotlin-friendly interface for that.

They don’t try to clone Flutter grammar, it was many rationale and insights in #compose why they decided to use this syntax, they switch just recently, before it was closed to JSX

I wish they were more open to explain those before but yeah, there are some good reasons in #compose why they did it like that

Well, it is definitely better than JSX, but I hope, it will move further toward kotlin dsl style.

There is no DSL in compose, it’s not how it works

I understand. But in my opinion it should look like dsl.

Do you have any particular example what do you expect? all suggestions about other syntax that proposed in #compose actually do not work

Yeah, but scope does not necessary mean receiver. It could be just that - scope with functions

So how you add arbitrary function to this scope?

By extending it obviously

do you expect that each componetnt should be extension function explicitly? Like

fun ComponentContext.TextView()

?

Yes. That is what I expect when I see the syntax

See this discussion with rationale about extensions syntax: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1558440714121300

Thanks, I will read it

I wish they were more open to explain those before

@sergio250 Isn’t they are super opened? They explain each decision to anyone who has a particular question, even if a few people see the answer in some old thread in compose channel of semi-closed slack, they working on blog posts to explain to wider list of developers their plans and decisions, evaluate every proposal and they have a lot of things to do instead of explain anyone even basic things that you can find in existing samples, and so many do not appreciate their effort (“Compose sucks”) and expect full blown documentation and explanations of 1 year of research right now and writing hype blog posts with ridiculous opinions even do not figure out how it actually works now and I feel bad about Compose Team in this situation when they so opened and ready to discuss

I think the main annoying point are those capital letters. It is not critical in the grand scheme of things but I think that it just produce wrong impression for kotlin-oriented guys. It seems like either they've came from .Net or indeed put logic inside constructors. With small letters it becomes much more understandable for regular kotliner.

.> main annoying point are those capital letters. Honestly looks as super minor for me, at least on this stage

Don’t get me wrong, I think the library has a bright future and the people behind it sure has put a lot of work into it and as a small open source lib maintainer myself I truly value what they are achieving. It just sounds confusing that in the IO talk, Google told devs to go and try compose and give them feedback about it to find out that the library has a lot of features and docs missing, from testing to lifecycle and holding state for components, that’s still not possible. I think the blogpost already makes it clear that we understand the effort and the potential of such tool. I can see how it all comes from a communication issue, that’s what I was trying to say.

I think there is no difference between:

Row {
   Text("Title")
   WebView(url = url)
}

and

row {
  text("Title")
  WebVeiew(url = url) // this is Android Framework view, not composable
}

It of course depends on your habits. My problem is that it looks as either non-kotlin or badly written kotlin (not that is is bad, it just looks so). In this particular case, I still think that the difference is quite important. For example, you see composable functions and their difference from non-composable object. Non-composable function looks really out of place, it also should be a function, but it is not.

I think there are double standards and huge level hypocrisy to apply such requirements not even to alpha version of a library, just to preview shared with other to get opions and participate in development from 99.9999% of developers who do not apply those requirements for own work even for release project

I think the idea to publish early preview is good. So we can have such discussions

But they don’t have docs!!!

It is OK, I do not have them as well 🙂

And a little disclaimer, I do not work on Andoroid right now, so my interest is only from language design point of view.

I think the blogpost already makes it clear that we understand the effort and the potential of such tool

Yes, mentions this once and also a lot of loud opinions without proper understanding or attempt to figureout some questions before publishing the article, especially when you can ask any question to any of authors of the library

I also think it’s great we can have these discussions! That’s why I like the blogpost, because it brought together some really interesting insights about how compose work from the authors themselves

yes, publishing tech article with a lot of wrong opinions, assumptions and mistakes and complaining in #compose because everyone from compose team tells him that he’s wrong and that it’s not his fault. but fault of documentation

No prob Andrey, I get your point

language design point of view

@altavir I think from the language design point, the biggest thing is that it pushes compiler plugin API a lot, so we probably get it sooner now

Well, we definitely are waiting for this one. For multi-receivers too.

I just think making questions and bringing potential pain points to the table is a good thing in the end. Saying that maybe the project is lacking some documentation, while reasonable, is also correct, and a form of feedback I personally would appreciate but I guess that’s where we disagree

Multi-receivers is nice, but I really think that it’s not even close a blocker for compose, you always can introduce additional explicit syntax if there are some reasons for this.

Yes, it could be avoided. But, you yourself gave the link about the design decision. And the lack of multi-receiver is the main reason for unscoped composable functions

and a form of feedback

I believe that loudly publishing article without enough research is not feedback

Well, I did not really look at it from suspend angle. It makes some sense. Still, most suspend functions are currently launched inside the

CoroutineScope

, thus limiting the visibility of inner functions and enforcing correct structure.

most suspend functions are currently launched inside the

CoroutineScope

But suspend function itself has nothing to do with CoroutineScope, it’s for background jobs, you can call suspend function from another suspend function and they share context and have context of parent suspend function, exactly the same what Compose component does

But you can't just run suspend function from the plain code. It does have implicit parameter, so I agree that it is similar to composable idea

But you can’t just run suspend function from the plain code

You can do this from another suspend function and you have primitves to create suspend lambda from the plain code, and stdlib even do not have concept of CoroutineScope, it’s an abstraction for launching coroutines in background

Yep, but in coroutines you have coroutine primitives and builder functions. You can use builders or, if you are competent, use primitives. Mostly everything works on a library level. Compiler has only basic support for suspends. Compose seems to hide everything in the compiler plugin.

hide everything in the compiler plugin

it hides composition in the compiler plugin (same as suspend function continuation in the compiler) and tree diffing mechanism, but all rendering code is also just library, not a part of compiler plugin