Some questions about syntax: If all dimensions are in `dp`, why can't I just put a number, instead o...

# compose

[Fudge]

Some questions about syntax:
If all dimensions are in dp, why can't I just put a number, instead of doing <number>.dp?
What is the deal with the + operator (in style = +themeTextStyle { subtitle1 } for example) ? I've read the documentation about it, but I still don't understand the need for it.

[ribesg]

Since when are all dimensions in dp?

[Fudge]

That's the way it seemed to me, that all of the composables accept DP

[miha-x64]

unary plus is really messy

[Fudge]

This is what I'm talking about with the dp btw

[miha-x64]

What is the type of number.dp expression?

[Fudge]

DP 😁

[Fudge]

this is indeed the case regarding components @ribesg

Component APIs specify their
 * dimensions such as line thickness in DP with Dp objects.

[Fudge]

* IMPORTANT:
 * This global operator is TEMPORARY, and should be removed whenever an answer for contextual composers is reached. At that time, the
 * unaryPlus operator on the composer itself is the one that should be used.

Hmm, I'm thinking the unary plus syntax won't be a thing in the future then?

[Leland Richardson [G]]

the unary plus will indeed go away. the design of effects will be simplifying

[Leland Richardson [G]]

regarding dp: I believe we are trying to draw a hard line between dp and px as units, and this was what we landed on. open to suggestions on what we could do better

[Leland Richardson [G]]

if you just have Int as the type, then there is no compiler help to tell you what kind of units it’s expecting, and you have to rely on, say, the parameter name: widthInPx: Int

[ragunathjawahar]

IMO, I like the unary + operator. Because, most of the time code becomes hard to understand and maintain because we mix logic and effects. The + operator visibly makes a distinction and helps identify an effect. This has added benefits during code reviews and architecture. Whenever, I see an effect I could use the visual cue to ensure that the effect does just one thing. And also ensure that my effect does not have business logic in it. (i.e.) My state gets updated outside the effect.

[ragunathjawahar]

Also, we could use tooling to ensure state mutation does not happen inside effects.

[Fudge]

I like the tooling idea more 🙂

[Fudge]

How often is it required to handle a px? I come from Flutter where that is not even a concept

[Leland Richardson [G]]

@ragunathjawahar this was kind of my original intent with the +. It’s strange at first, but having a visual clue to tell you when something different is going on can be a good thing

[Leland Richardson [G]]

what i ended up realizing was that the things that make Effect special are pretty darn similar to what make @Composable special, and i’m trying to unify them (though we are still thinking that maybe they need to be a little bit different)

[Leland Richardson [G]]

on the tooling side, the IDE will eventually make it more clear when you are calling something that is @Composable or an effect visually, and i’m hoping that this is enough

[Leland Richardson [G]]

the problem with that is those visual clues aren’t present in, say, code review

[Leland Richardson [G]]

@Fudge good question. APIs are still evolving so it’s unclear everywhere it will be necessary, but right now all of the drawing and layout APIs end up resolving down to pixels. you’re right though that these won’t end up being used in user-land code very often

[ragunathjawahar]

How would the unified API surface look like? Is this something that you can share?

[Fudge]

Thanks for great answers @Leland Richardson [G]

[Leland Richardson [G]]

well, my hope is that an “effect” is really just a composable function with a return value, but so far we have required composables to return unit, and that is being treated as an implicit assumption in several places that we’re not sure we can break

[ragunathjawahar]

What happens if I try to add a Text to a composable function that is an effect? I feel that the lines are getting blurry if the API tends to move towards that direction.

[Leland Richardson [G]]

yeah that’s a question we’ve been asking ourselves as well. I think my question is: is that something that we should just lint against? or should we prohibit it entirely at compile time? I can’t think of a good reason to do it or to want people to do it, but perhaps there’s a really nice pattern out there that we haven’t discovered.

[Leland Richardson [G]]

not sure how good of a reason to do it that is, but if the math of it works out then i’m drawn to the unification of the two concepts

[romainguy]

@Fudge The underlying drawing APIs work in pixels

[romainguy]

Also, sometimes you want to do pixel-perfect drawing and it can be useful to use px as a unit

[George Mount]

FWIW, we have 3 dimension classes that you commonly use -- Dp, Sp, and Px. This allows you to have constants for these values (in the code) and convert them at runtime as needed. For example, if you want to specify that something should be exactly 2 pixels high, you can do that, even if the API accepts DP. We think that most app developers would prefer specifying almost everything in DP with a few in PX and SP. It is easy to get units wrong when they're naked floats.

When doing layout, we also have IntPx to avoid any confusion of rounding errors.

[Fudge]

I would like to see the usage percentage in practice and continue this discussion

[romainguy]

I’m not sure it would be helpful. This has the benefit of being explicit (esp. if you mix and match with the existing view system were all values are in pixels, except when they’re in dp…) and allows for pixel-perfect layout and rendering when needed

[Fudge]

My meaning is that we would have width = 10 when meaning dp, width = 10.px when meaning px and width = 10.sp when meaning sp.
If 99% of use cases are dp then that makes .dp boilerplate in my opinion.

[romainguy]

Given that all the existing APIs assume pixels when you do width = 10 I think it would be a bad idea to go this way

[miha-x64]

interface Dimen
inline class Px : Dimen
inline class Dp : Dimen
inline class Sp : Dimen

[Leland Richardson [G]]

FWIW, if you’re targeting an interface, having it be an inline class will end up creating more boxing/unboxing operations than you’d expect and it would actually be a net negative to mark it inline

[romainguy]

Inline classes can cause a lot of boxing in general too

[miha-x64]

I know that upcasting leads to boxing. APIs should have overrides to avoid this.

[Leland Richardson [G]]

but then the value of the Dimen interface goes away. any function with width: Dimen would represent an upcast

[Leland Richardson [G]]

it’s hard to define APIs that leverage inline classes well

[Leland Richardson [G]]

i don’t think the idea of using Int to represent Dp or Px and classes for the less common ones is a bad idea… it just has trade offs like romain mentioned, and we are trying to navigate those thoughtfully