<@U3ZLHBTLG> What do you think about adding overlo...

# splitties

[ispbox]

@louiscad What do you think about adding overload for view.dip() to be able to deal with floating values where needed. Because without that you have to use your own helper or write extra code:

elevation = dip(4).toFloat()

[ispbox]

Or dp(4) should be used? I'm just not sure about convention, but for me dip() fits better both for float and int.

[louiscad]

@ispbox Yes, dp is for that.

[ispbox]

OK, but what is the purpose for having both dp and dip? What`s wrong with overloading of dip?

[ispbox]

You can argue that overloads are only possible for different parameter types (now they are both Int), but how to make elevation of 3.5f? 🙂 It should be float anyways.

[louiscad]

@ispbox You can't overload based on return type.

[ispbox]

This is what I was saying in my last comment. I would propose these two methods:

dip(Int): Int
dip(Float): Float

They could be easily overloaded. The only "problem" is that you have to write:

elevation = dip(4f)

But that is not a problem, it is a feature to be able to set floating point elevation, i.e.:

elevation = dip(3.5f)

[louiscad]

Hum, I see, could be a great feature, I agree

[louiscad]

Just checked the sources, and you convinced me! Do you want to submit a PR on the develop branch or should I do it myself?

[ispbox]

Sorry, Louis, but please do that yourself, as it could influence some other code / public API. I don't know whether you should mark old API as deprecated or something similar (I mean dp()).

[louiscad]

@ispbox Now I'm realizing I can equally use dip or dp. Please vote here: https://kotlinlang.slack.com/archives/CHJP9K00L/p1569187453013900