object-destructuring-by-name_kt.kt

# language-proposals

[jmfayard]

object-destructuring-by-name_kt.kt

object-destructuring-by-name_kt.kt

[gildor]

There is a feature request about this:
https://youtrack.jetbrains.com/issue/KT-19627

[gildor]

And your proposal will not work, because it backward incompatible with existing syntax, issue above has alternative for this

[jmfayard]

@gildor what do you mean it would not work? It is an existing syntax that works right now.
https://pl.kotl.in/kxzTHii2E

[gildor]

Yes, it works now, but it positioned destructuring, not named destructuring,

Isn’t you propose to have named destructuring like in JS

[jmfayard]

I would really like the proposal you linked to be implemented, but in this case since you are just copy/pasting the same list of elements it’s hard to do a mistake.

[gildor]

Also you don’t need intermidiate list just use underscore:
https://pl.kotl.in/EIoz3HETz

[gildor]

No need to copy/paste

[jmfayard]

Yes but your code breaks if I reorder the properties in the data class

[gildor]

Yes, that what I’m saying, that there is a feature request about this (see link above). And we need special syntax for named destructuring

[gildor]

Existing syntax will be always positioned

[jmfayard]

Then we both agree

[gildor]

One more problem for me with this feature (tho I support it in general) is that I think it would be nice, but pretty minor improvement comparing to:

val city = person.city
val country = person.country

[gildor]

Or especially:

println("City=${person.city} and Country=${person.country}")

[gildor]

Of course there are much more complicated cases, I just see not so many of them on practice

But, because we already have positioned destrucutring, I would like to see named as a better alternative

[jmfayard]

I could see it being quite useful in a when clause for example:

when(val {city, country} = person) {
   city.isGreat() && country in EUROPE -> ...
}

[gildor]

if (person.city.isGreat() && person.country in EUROPE) {}

Also proably even more readable

[jmfayard]

If your when statement is large, it improves signifianctly the signal to noise ratio

[gildor]

Yes, that my point

[gildor]

if it’s large it will be not so great with destructuring too

[gildor]

Than I would just switch to extension functions, or local variables etc

[gildor]

Also if you format it properly it become even more readable even without destructuring

[gildor]

I don’t want to say that it’s bad, I just want to be realistic about this feature in general. Yeah, it’s kinda nice, but probably most of use cases of it wouldn’t pass our code review because it’s not very readable in many cases, even if it a bit shorter

So it’s in the list of proposals for me that I would like to see, but probably they just too complex to implement and I would prefer to improve other features of Kotlin instead

[jmfayard]

I put two when statements together, don’t you first the first more readable?
https://pl.kotl.in/zokVPr6bH

[jmfayard]

And yes it’s not a must-have, but still nice and I sort-of like my hack

[gildor]

Honestly I don’t see big difference in this case

[gildor]

also hack with list looks really bad for me, I mean I wouldn’t use it in a real code

[gildor]

Also there are ways to improve readability in your sample:
person.city.hasTech().not() -> !person.city.hasTech() or even special extension:

val techCities = listOf("Paris", "Berlin", "London", "New York")
person.city !in techCities

Which for me reads even better without destructuring

Also

city =="London" || city == "Paris" -> city in listOf("London", "Paris")

Or even:

val expensiveCities = listOf("London", "Paris")

person.city in expensiveCities

[jmfayard]

@gildor One reason I like my pattern is that it is much more general. Destructuring only works with all properties of a data class (or tuple). Here you can have let say a Service that is not a data class and do
val (a,b,c) = with(service) { listOf(a, someFunctionReturningB(), this.a.c) }

[gildor]

I think it’s a lot more messy than:

val a = service.a
val b = someFunctionReturningB() // or a.someFunctionReturningB()? One more reason to avoid scope in this case
val c = service.a.c

[jmfayard]

That’s also possible, I think that’s a matter of habit or taste? I like to minimize the number of statements as long as it’s readable.
One thing though is that it’s better to use Triple instead of listOf() for when we have different types. I updated my example