https://kotlinlang.org logo
#feed
Title
a

altavir

05/21/2019, 11:32 AM
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?
👍 2
s

sergio250

05/21/2019, 11:44 AM
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
a

altavir

05/21/2019, 11:45 AM
I think that they tried to clone Flutter grammar. I really hope, that there will be normal kotlin-friendly interface for that.
g

gildor

05/22/2019, 9:00 AM
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
s

sergio250

05/22/2019, 9:02 AM
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
a

altavir

05/22/2019, 9:02 AM
Well, it is definitely better than JSX, but I hope, it will move further toward kotlin dsl style.
👍 1
g

gildor

05/22/2019, 9:03 AM
There is no DSL in compose, it’s not how it works
a

altavir

05/22/2019, 9:04 AM
I understand. But in my opinion it should look like dsl.
👍 1
g

gildor

05/22/2019, 9:04 AM
Do you have any particular example what do you expect? all suggestions about other syntax that proposed in #compose actually do not work
Why something that is not DSL should look like DSL?
There is no receiver, no blocks, it’s composition of functions
It’s just different approach. For example check this thread: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1558480278211900
a

altavir

05/22/2019, 9:06 AM
Yeah, but scope does not necessary mean receiver. It could be just that - scope with functions
g

gildor

05/22/2019, 9:06 AM
So how you add arbitrary function to this scope?
a

altavir

05/22/2019, 9:06 AM
By extending it obviously
g

gildor

05/22/2019, 9:06 AM
do you expect that each componetnt should be extension function explicitly? Like
fun ComponentContext.TextView()
?
👌 1
a

altavir

05/22/2019, 9:07 AM
Yes. That is what I expect when I see the syntax
g

gildor

05/22/2019, 9:07 AM
See this discussion with rationale about extensions syntax: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1558440714121300
a

altavir

05/22/2019, 9:08 AM
Thanks, I will read it
This is all about lack of multi receivers then. Well, you know, where I stand about it. Starting functions with capital letter still looking terrible for me. It is habit of course, but one hard to kill.
g

gildor

05/22/2019, 1:03 PM
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
1
This is all about lack of multi receivers then.
@altavir Yes it would make decision different, but it’s just a proposal, they cannot hold project just because some language feature is not there and even not confirmed and do not have proper design
Starting functions with capital letter still looking terrible for me
Like many builder functions, even kotlin stdlib, but I agree, case there is different.. It’s just current convention tho, but I see reasons there, it will look like View declarations, and works well with existing views interop
a

altavir

05/22/2019, 1:14 PM
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.
g

gildor

05/22/2019, 1:15 PM
.> main annoying point are those capital letters. Honestly looks as super minor for me, at least on this stage
s

sergio250

05/22/2019, 1:16 PM
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.
g

gildor

05/22/2019, 1:17 PM
I think there is no difference between:
Copy code
Row {
   Text("Title")
   WebView(url = url)
}
and
Copy code
row {
  text("Title")
  WebVeiew(url = url) // this is Android Framework view, not composable
}
from testing to lifecycle
@sergio250 Exactly! This is available and was mentioned on the only talk about compose on IO, they had example on one of slides > a lot of features and docs missing This also was mentioned in talk, that many features are not there, it’s just a preview, not an alpha
holding state for components
It’s also possible and mentioned, but in a different way
a

altavir

05/22/2019, 1:20 PM
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.
g

gildor

05/22/2019, 1:21 PM
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
a

altavir

05/22/2019, 1:22 PM
I think the idea to publish early preview is good. So we can have such discussions
g

gildor

05/22/2019, 1:22 PM
But they don’t have docs!!!
a

altavir

05/22/2019, 1:23 PM
It is OK, I do not have them as well 🙂
g

gildor

05/22/2019, 1:23 PM
oh my god! no full docs! And annotations are there and they not needed! (obviously, because I even don’t know how compose work)
a

altavir

05/22/2019, 1:23 PM
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 that the agitation right now comes from the fear of new Spring or JSX. I am sure that if google guys are reasonable, some good solution will be found in future
g

gildor

05/22/2019, 1:27 PM
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
s

sergio250

05/22/2019, 1:28 PM
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
g

gildor

05/22/2019, 1:30 PM
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
Sorry to be triggered so much
but I really read too many bad articles, tweets and chats about compose and people now have opinions about huge project in early stage so fast, just because of one single thing that they don’t like and usually also do not understand
s

sergio250

05/22/2019, 1:34 PM
No prob Andrey, I get your point
g

gildor

05/22/2019, 1:37 PM
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
a

altavir

05/22/2019, 1:37 PM
Well, we definitely are waiting for this one. For multi-receivers too.
s

sergio250

05/22/2019, 1:39 PM
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
g

gildor

05/22/2019, 1:39 PM
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.
maybe the project is lacking some documentation
of course, they have some documentation during early stage of development, it’s already nice, also as they said, they will work on blog posts to explain how it works under the hood and to explain some decisions
a

altavir

05/22/2019, 1:41 PM
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
g

gildor

05/22/2019, 1:41 PM
and a form of feedback
I believe that loudly publishing article without enough research is not feedback
It’s one of the reasons
but with current design it’s not clear for me how receiver would be much better
also using member extension functions is really clunky, even with 1 receiver and
with
unscoped composable functions
Why do you think it’s bad? it’s really similar to
suspend
functions
a

altavir

05/22/2019, 1:54 PM
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.
g

gildor

05/22/2019, 1:57 PM
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
a

altavir

05/22/2019, 1:58 PM
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
👍 1
g

gildor

05/22/2019, 1:59 PM
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
suspendCoroutine
(and more high-level
runBlocking
) are things that can be called from the plain code and create suspend lambda
a

altavir

05/22/2019, 2:02 PM
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.
g

gildor

05/22/2019, 2:08 PM
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
and it mentioned already, that MPP and other use cases will be possible (tho not necessary will be provided by composer team)
it needed not only for MPP, but also for testing, support of preview etc, so no, not everything is part of the compiler plugin, only necessray parts, and those parts know nothing about Android, Ui or rendering
4 Views