Hi,
I was thinking along this line: kotlin could allow developer to create a class that support destructuring, but yet do not have to define componentX function for each and every class properties that could be destructured.
Why can’t kotlin able to implicitly define componentX function for each and every class properties by default. This could really help reduce code clutterness and save typings.
Javascript/Typescript do not even require developer to define these componentX functions in order to use destructuring.
In the java/kotlin world and indeed for most strongly typed languages the order of properties doesn’t matter and is often considered a cosmetic choice. As such it should not effect the execution of a program so destructuring based on property declaration order is a bad idea.
Also you are probably doing something wrong if you are writting your own componentX functions all the time. Normally you can just use data classes instead. I would argue that if a class is too complex to fit within the limitations of data classes it’s probably also to complex to destructure it without introducing error prone or buggy code.
Hi,
Thanks for the reply! I don’t even realize that data class can actually auto generate componentN() for us. I only know that for normal class, i have to explicitly declare componentN function.
Although i would be hoping that such auto generation could be done for normal class as well. but as you mention, “if a class is too complex to fit within the limitations of data classes it’s probably also to complex to destructure it without introducing error prone or buggy code.” .
For posterity, I want to point out that in the Java/Kotlin world, the ordering of properties does matter. Properties are initialized in the order they are declared, and has to be taken into consideration during initialization/construction when trying to access properties.
In fact, data classes generate componentN() functions based on the order that they are declared!
I believe the original poster was asking for a language construct that automatically generates componentN() functions, and the answer is that there is such a thing - data classes, which generate them in the order of the data class’s parameters.
Yes, but it has no effect on other classes. Initilazation order is an implementation detail. Changing the order of properties should not effect any other code outside of the class.
Yes data classes are an exception to this. That’s why I suggested using them. I was arguing agains implicit componentX functions for none data classes which is a bad idea.
There are cases where it does; for example, in a JPA @Entity, it affects the order of fields in the corresponding database table.
(Those may be corner cases; but you could see destructuring of data classes as a corner case too — most other uses of destructuring, such as arrays and lists, have an clear inherent ordering.)
We’re going a bit off topic here, but now I’m curious what you’re talking about. In what languages (I presume dynamically typed languages) does the order of properties matter, and how would it affect code outside of the class? And how does that contrast to Java?
Order of properties in Java/Kotlin affects initialization and reflection, at least as far as I can think of right now.
I’m not that familiar with dynamic languages so I didn’t want to make any statements about them. Maybe they don’t care about property order, maybe some do. I personally don’t know.
One example I can give you however is C a loosly typed language (well I guess we can argue about C being strongly or loosely typed but we can probably agree that the type system is not as strong as kotlins) . The order you define fields in a struct defines the memory layout of the struct which can have a significant impact on your program if you use any kind of pointer arithmetic (which you probably are if you are using plain C or even C++ in many cases).
But even in C, you can’t rely on the exact memory layout, due to issues such as padding/alignment. (In fact, the C standards don’t even require fields to be stored in their declared order! Though most do, of course.)
So while, yes, the order of fields within a struct is visible in some ways, I can’t recall ever relying on it (and C was my main professional language for several years).