When writing Kotlin code it becomes a pain to constantly create entire code blocks just for a single function; ex.
companion object {
fun something() : Int {
return 1 + 1;
}
}
Could a more concise syntax for this be allocated? ex.
companion fun something() : Int {
return 1 + 1;
}
This would really help clean up a lot of classes
It would be nice if they allowed us to use the JVM static annotation on non-companion functions.
Iâm not sure that the case of having only a single function or field in a companion object is super common. Even if it were, this is really just the static keyword isnât it? The arguments against that are far more established.
Neither is delegation, but we have syntax sugar for delegating to a type using the âbyâ keyword.
Not at all, I am not proposing that this syntax be allowed for multiple fields, but simply for when you only have a single property/function within the companion object. It would allow for its declaration to be much more concise.
A lot of language design is about return on investment. Delegation is an awesome pattern that benefits a lot from language-level support. Being able to express a very specific situation in 8 fewer characters? Maybe not. Itâs the difference between support for an entire programming pattern and support for very specific âboilerplateâ reduction.
I think the extra limitation of only being able to have one actually hurts the proposal, if anything.
Say I have a âcompanion funâ or property and I want to add another. Now, I have add the two to a new companion object and remove the keyword from the original function. While not a huge deal, itâs still extra work in refactoring that didnât exist previously.
In my opinion, this would also be counter-intuitive to people coming to Kotlin from Java. This almost looks like some âstaticâ keyword, but then itâs not.
I donât really consider this to be simply for reducing the amount of characters you type. The point is to reduce the amount of ceremony involved in doing something like this, which IMO is one of the core aspects of Kotlinâs design.
I can understand how this might be an issue if you are programming in notepad, but when using IntelliJ, this is not an issue. It has many intents that can convert code to be almost anything, even between languages. If it detects that you try to do this, it can easily move them both into a single companion object.
I agree, but honestly, the entire language is almost counter-intuitive considering its relatively odd syntax for doing some things. This is an issue that persists beyond just this one thing. You wont truly know the language, until you learn the language. This seems like a moot point. IMO
May I ask you for an example? What do those functions do? Why are they not members of the class, or members of another object, or top-level functions?
Yes, in a current project, I have a constant that represents time to wait before cancelling a specific task. To do this I must do:
companion object {
private const val DROP_TIME = 40
}
This would be much nicer if for one, constants could be in other places besides objects and top level, or this constant could be declared on a single line. Perhaps:
private companion const DROP_TIME = 40
And yes, I omitted the âvalâ on purpose, because its existence in constant declaration is odd to me. "const"s can never be var, so why explicitly have to declare it as val. Just seems like more useless ceremony.
I know, itâs not a very pretty solution, but itâs what Iâd prefer over entire code blocks for a single property/function.
Why not simply put it as a top-level variable in the file? Does it really have to be part of the class?
If you want it to be âprivateâ to the class, then this would rule out using a top-level declaration.
I agree with the OP that it would be nice to have a shorter syntax for dealing with single non-instance class members though I wouldnât be surprised to see âtrueâ static members introduced to the language (either in addition to or instead of companion objects) which would solve this and other problems.
With regard to the âconstâ modifier, I think the reason why you need to specify âvalâ as well is so that âconstâ doesnât have to be a keyword i.e. it can be used in other contexts without (too much) confusion.
Well, you can define something like
private const val SOMETHING = "something"
public class Test {
fun someFun() {
println("$SOMETHING")
val test = SOMETHING + "value"
}
}
And it compiles just fine. Because itâs a const, it gets inlined. BUT a new class TestKt is created that contains a private static final SOMETHING in it, so a bit of waste.
Removing the const creates a public get in the TestKt class, so you might be able to access it in Java, but canât in Kotlin.
If you use a companion object, the companion gets created as an inner static class.
So you can create it as a top-level const, saving the typing of âcompanion objectâ⊠Not sure what the recommended/better approach is.
If the const canât be inlined, a public access is created, but itâs a non-obvious name.
I think itâs a case of style choice. Companion keeps it more encapsulated if youâre using Java too. If youâre 100% Kotlin, then you can safely save the extra typing by putting the const at the top-leve.
This style does not conform to what I proposed, this top level declaration will not be accessible through the class like companion members can.
Functionally it is the same. It is scoped to the file (or artificial class created for the file), so yes, if you created another class in the same file, it is not scoped ONLY to the one class.
You marked the function/const as private, so Iâm not sure what you mean as âaccessible through the classâ. It is accessible in the class, and has limited scope because itâs private.
As itâs private, itâs not accessible anywhere else anyway.
What am I misunderstanding here?
The most recent post of mine was only an alternate example of where it could be applicable, the focus of this thread is the example in the OP. Thatâs what youâre misunderstanding.