Thoughts on Kotlin’s Future Features Survey
Thoughts on Kotlin’s Future Features Survey
One dev has reviewed JetBrains' recent future feature survey on Kotlin. See how the community voted and what this interested party is looking forward to.
Join the DZone community and get the full member experience.Join For Free
The CMS developers love. Open Source, API-first and Enterprise-grade. Try BloomReach CMS for free.
So, the survey results for Kotlin’s future features are in. Let’s talk about that.
First off, I’d like to say that I’m sad that I wasn’t able to participate in this. It’s not that JetBrains stopped me, I just wasn’t able to watch at the time.
Next, you should familiarize yourself with the different proposed features so you know what is being talked about.
I find it interesting the differences between the two sets of surveys JetBrains did. For example, on their first graph, “Private members accessible from tests” is right near the middle (and also has the largest number in the “Unwelcome Features” graph), but is the third highest (of 20) at the Kotlin 1.1 Event. “Collection comprehensions” are also interesting in that they’re in the middle of both positive surveys, but has the second highest negative rating. Again, “Static members…” are in the middle-ish in both positive graph, but have the third highest negative count.
All these numbers are a little confusing as to what people want overall, so I put together a graph of my own which is a combined number. To combine then, I added up the positive numbers from the two graphs and normalized the numbers to a percent of the highest number, which limits the numbers to a maximum of 100. I did the same kind of normalizing with the negative numbers, except I constrained it to 80. I constrained it to 80 because I felt that, since they won’t have as well averaged of numbers due to only being in one of the two polls, they shouldn’t have the same amount of weight as the positive numbers. After putting together my graph, I went back and tried 20 and 100 weights for the negative numbers, and it had very little effect on the overall rankings, so I just kept it at 80. I then subtracted the negative numbers from the positive numbers and added a flat amount to make all the numbers positive (for the graph’s sake). And here’s the result:
So, just as JetBrains concluded, “Truly immutable data”, “Collection literals”, and “SAM conversions for Kotlin interfaces” are the top three contenders, and with a considerable lead, too. The next three are “Multi-catch”, “Slices for lists and arrays”, and “Inline classes/value classes”, with the amount of support dropping at a fairly quick pace.
Now we’ll go through each feature proposal and I’ll give you my thoughts on them.
I feel this is practically a must-have if you don’t want to have to repeat code in your catch blocks. I’m slightly concerned this is only in 4th place.
Overloadable Operators | and &
I’m fairly indifferent on this. On one hand, I think they’d be useful for DSLs (especially using | as a piping mechanism), but on the other hand, I think these operators will be abused more than most. I probably don’t have to worry about it, though, due to its low-lying status on the chart.
Short Notation for Enum Constants
Nice to have, but not great. Coming in at #7, it will likely be added someday, but not soon.
Private Members Accessible From Tests
Oh, HELL no! If you feel you need this, then you’re not designing your classes for testability or you’re testing something that doesn’t need to be tested. Thank goodness that, despite its popularity in the second survey, it still ends up solidly at the bottom of the chart.
Support Package-Private Visibility
With the Jigsaw module system, this will be much more useful than it would be otherwise, since packages will finally be limited to only what the original authors put in; you can’t just make a random class and declare it to be in a package of some library. On the other hand, generally you have a certain set of the classes in the package in mind to having access to that variable, function, or class, so you should group them into the same module. But if you want everything to have access without putting it ALL into the same module, package-private would allow you to do that. We should probably have it, just in case. Sadly, this will also add a new keyword to the language.
As much as I like the idea, Kotlin doesn’t really need them due to their nice functions for creating collections. Plus, I would assume that the literals lock you into a particular implementation. That assumption is apparently wrong, though, because supposedly JetBrains figures that, “Particular types of collections created my be determined by libraries/operator conventions.” Until they show me how that works, I’m surprisingly against this feature. But it looks like most of you want the literals, so I’m outvoted.
I love these in Python, but I may surprise you by saying that I’d rather not have them in Kotlin. First, with Kotlin’s super short lambda syntax sugars, a single filter and/or map is nearly as short as a comprehension. Secondly, filter/map are more flexible, since they can be called directly from the collection or from a Sequence, and there are a TON of other functions like them that a comprehension can’t use. Lastly, they’re always confusing to newcomers, which is probably why it’s so low on the list.
Slices for Lists and Arrays
I haven’t needed them much in Python, but they’re a welcome addition in my book.
Inline Classes/Value Classes
I appreciate the effort that JetBrains is giving in order for us to have some semblance of value types, but I think it won’t be used enough to make it worth it. I could be wrong. Also, they were come up with a syntax that doesn’t require any new keywords or anything. I’m not against it, but it’s certainly not a priority to me.
I think we should have this, though I’m not likely to use it much.
Optional (Trailing) Commas
I’m actually all for both options, which a slight preference for no commas with new lines. Heck, Haskell and Lisps don’t really use commas at all, and they’re fine. I feel like the trailing commas option would have done better if it were separate from the other, but I really like both options. Too bad no one else seems to.
I could go either way, and apparently, so can the rest of you.
SAM Conversions for Kotlin Interfaces
Type aliases largely take care of this problem, but they don’t solve all of it. The ability to have multiple non-abstract methods comes in handy, too. Now you won’t need to use extension methods to add functionality to functions.
Annotations for Static Analysis
What I’m most interested in with these is whether they can compile micro-optimizations into the code. For example, a @Pure function could somehow be flagged for JVM caching or something. I’m pretty sure that’s not the case and won’t ever be, but that would be cool. But, even just using them for static analysis, these could be useful; they’re not a game-changer, but they are useful. Being in the middle of the list, though, they’re not likely to happen for a while.
Yes, please! You want to swap variables? Just write “(a, b) = b to a”. This comes in handy more than you would think, but sadly, most voters didn’t agree.
Use invokedynamic to Compile Kotlin
Here’s a nice optimization that apparently most people don’t care about. I personally would like my lambdas to compile smaller and run a little faster like they do in Java 8. Why don’t most people also want this?
Static Members for Kotlin Classes
I vote yes. This is my LEAST favorite feature of Kotlin. Everything else is built around making the code a little more concise (even though extra characters are often added due to colons and the “val”, “var”, and “fun” keywords), but requiring a companion object is the stupid opposite of that. Not only that, but if you want it to be compiled to something static in Java, you need to also add an annotation to it. Even one of the Kotlin designers kind of regrets not having static in the language, but apparently, most people don’t share this view.
Truly Immutable Data
This could(/should?) be done through the static analysis annotations. Otherwise, it’s almost guaranteed to need a new keyword. I’m all for the feature, otherwise, and everyone seems to agree with that, since it’s number one on the list.
Subject Variable in When
Sure, why not? The biggest advantage comes from when you need to access the variable and you’re trying to use the when for a single-expression function. Otherwise, it’s not really a big deal to simply add the variable declaration before the “when” expression. Seems to be of middling priority for most voters, though.
Vararg-Like Treatment of Data Classes
This would be cool, but I’m curious about how well it reads. It’s probably fine, but the votes show that most people just don’t care.
So, that’s what I think about that. Let me know your opinions in the comments below.
Published at DZone with permission of Jake Zimmerman , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.