You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am writing to share suggestions regarding the use of ImmutableList within the Kotlin ecosystem, particularly in the context of Android development using Jetpack Compose. As a Kotlin developer, I have greatly appreciated the language's pragmatic approach and its powerful features that generally promote a smooth development experience. However, I've encountered a specific issue with ImmutableList that I believe warrants attention to better align with Kotlin's philosophy and the needs of modern Android development.
While working with Jetpack Compose, the immutability of data structures is paramount to optimize UI updates and performance. Kotlin's ImmutableList initially seemed like a fitting choice to guarantee data integrity and promote efficient recompositions. However, a significant drawback arises from the fact that transformations on ImmutableList, such as using the map function, return a standard mutable List (backed by ArrayList under the hood). This behavior not only contradicts the expectations for an immutable collection but also forces developers to frequently convert results back to ImmutableList using toImmutableList(). This pattern results in excessive object creation, which is counterproductive and inefficient, particularly in a performance-sensitive environment like mobile development.
Given Kotlin's commitment to being a pragmatic language, the current handling of ImmutableList feels somewhat misaligned with this vision. The necessity to revert to mutable types and then convert them back to immutable ones is reminiscent of older Java practices, which Kotlin has otherwise superbly improved upon.
To address this, I propose the introduction of a more integrated approach for immutable collections in Kotlin, particularly for transformations like map, filter, etc. Ideally, these operations on an ImmutableList should return another ImmutableList directly, without intermediate mutable stages. This enhancement would not only reduce overhead from unnecessary object creation but also streamline development by adhering more closely to functional programming principles, where immutability is a standard expectation. Also, I don't want to create ArrayList. I want there to be complete immutability in the application.
Implementing this change could significantly improve Kotlin’s utility and efficiency in Android development, particularly when using Jetpack Compose.
Also, the implementation of Map, Filter, operations on an ImmutableList can be made as a separate library, and I really want there to be no ArrayList under the hood
I am writing to share suggestions regarding the use of
ImmutableList
within the Kotlin ecosystem, particularly in the context of Android development using Jetpack Compose. As a Kotlin developer, I have greatly appreciated the language's pragmatic approach and its powerful features that generally promote a smooth development experience. However, I've encountered a specific issue withImmutableList
that I believe warrants attention to better align with Kotlin's philosophy and the needs of modern Android development.While working with Jetpack Compose, the immutability of data structures is paramount to optimize UI updates and performance. Kotlin's
ImmutableList
initially seemed like a fitting choice to guarantee data integrity and promote efficient recompositions. However, a significant drawback arises from the fact that transformations onImmutableList
, such as using themap
function, return a standard mutableList
(backed byArrayList
under the hood). This behavior not only contradicts the expectations for an immutable collection but also forces developers to frequently convert results back toImmutableList
usingtoImmutableList()
. This pattern results in excessive object creation, which is counterproductive and inefficient, particularly in a performance-sensitive environment like mobile development.Given Kotlin's commitment to being a pragmatic language, the current handling of
ImmutableList
feels somewhat misaligned with this vision. The necessity to revert to mutable types and then convert them back to immutable ones is reminiscent of older Java practices, which Kotlin has otherwise superbly improved upon.To address this, I propose the introduction of a more integrated approach for immutable collections in Kotlin, particularly for transformations like
map
,filter
, etc. Ideally, these operations on anImmutableList
should return anotherImmutableList
directly, without intermediate mutable stages. This enhancement would not only reduce overhead from unnecessary object creation but also streamline development by adhering more closely to functional programming principles, where immutability is a standard expectation. Also, I don't want to create ArrayList. I want there to be complete immutability in the application.Implementing this change could significantly improve Kotlin’s utility and efficiency in Android development, particularly when using Jetpack Compose.
Also, the implementation of Map, Filter, operations on an ImmutableList can be made as a separate library, and I really want there to be no ArrayList under the hood
also reference: https://youtrack.jetbrains.com/issue/KT-68071#focus=Comments-27-9803975.0-0
The text was updated successfully, but these errors were encountered: