s

    sergio250

    3 years ago
    altavir

    altavir

    3 years ago
    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?
    s

    sergio250

    3 years ago
    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
    altavir

    altavir

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

    gildor

    3 years ago
    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

    3 years ago
    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
    altavir

    altavir

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

    gildor

    3 years ago
    There is no DSL in compose, it’s not how it works
    altavir

    altavir

    3 years ago
    I understand. But in my opinion it should look like dsl.
    gildor

    gildor

    3 years ago
    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
    altavir

    altavir

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

    gildor

    3 years ago
    So how you add arbitrary function to this scope?
    altavir

    altavir

    3 years ago
    By extending it obviously
    gildor

    gildor

    3 years ago
    do you expect that each componetnt should be extension function explicitly? Like
    fun ComponentContext.TextView()
    ?
    altavir

    altavir

    3 years ago
    Yes. That is what I expect when I see the syntax
    gildor

    gildor

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

    altavir

    3 years ago
    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.
    gildor

    gildor

    3 years ago
    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
    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
    altavir

    altavir

    3 years ago
    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.
    gildor

    gildor

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

    sergio250

    3 years ago
    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.
    gildor

    gildor

    3 years ago
    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
    }
    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
    altavir

    altavir

    3 years ago
    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.
    gildor

    gildor

    3 years ago
    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
    altavir

    altavir

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

    gildor

    3 years ago
    But they don’t have docs!!!
    altavir

    altavir

    3 years ago
    It is OK, I do not have them as well 🙂
    gildor

    gildor

    3 years ago
    oh my god! no full docs! And annotations are there and they not needed! (obviously, because I even don’t know how compose work)
    altavir

    altavir

    3 years ago
    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
    gildor

    gildor

    3 years ago
    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

    3 years ago
    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
    gildor

    gildor

    3 years ago
    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

    3 years ago
    No prob Andrey, I get your point
    gildor

    gildor

    3 years ago
    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
    altavir

    altavir

    3 years ago
    Well, we definitely are waiting for this one. For multi-receivers too.
    s

    sergio250

    3 years ago
    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
    gildor

    gildor

    3 years ago
    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
    altavir

    altavir

    3 years ago
    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
    gildor

    gildor

    3 years ago
    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
    altavir

    altavir

    3 years ago
    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.
    gildor

    gildor

    3 years ago
    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
    altavir

    altavir

    3 years ago
    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
    gildor

    gildor

    3 years ago
    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
    altavir

    altavir

    3 years ago
    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.
    gildor

    gildor

    3 years ago
    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