The correct way of making an enum class with param...

# getting-started

[victor-mntl]

The correct way of making an enum class with parameters for each value of the enum class is:
enum class Foo1 (val bar:Int) {FIRST(11), SECOND(222)}
so we would be able to call their bar value:
println(Foo1.FIRST.bar)

11

Now, if we look at this one (see that it is missing val between the parenthesis):
enum class Foo2 (bar:Int) {FIRST(110), SECOND(2220)}
in this case, bar doesn't exist on any call to a value of the enum class:
println(Foo2.FIRST.bar)

error: unresolved reference: bar

So, my question is, does it have any utility to create an enum class with arguments without a val or var expression (= with arguments that are not parameters)? Are the values 110 and 2220 in this example lost?

[Xavier F. Gouchet]

In theory you could have a property generated in the init block, based on the constructor parameters.

[victor-mntl]

Ok, right, I tried and it works. But to be clear, it doesn't work be inside a init block, let me show you:
(take into account that Foo3 is Foo2 adding what I marked:
enum class Foo3 (bar:Int) {
FIRST(_bar:_ 110), SECOND(_bar:_ 2220); //Added the ;
val bar2:Int = bar + 2 } //New line
In this case:
println(Foo3.FIRST.bar)

error: unresolved reference: bar

println(Foo3.FIRST.bar2)

112

[victor-mntl]

If I do the same with an init block:
Ok, right, I tried and it works. But to be clear, it doesn't work be inside a init block, let me show you:
(take into account that Foo4 is Foo3 putting the last line inside an init block):
enum class Foo3 (bar:Int) {
FIRST(_bar:_ 110), SECOND(_bar:_ 2220);
init{val bar2:Int = bar + 2} }
In this case:
println(Foo3.FIRST.bar)

error: unresolved reference: bar

println(Foo3.FIRST.bar2)

error: unresolved reference: bar2

[victor-mntl]

So, a new question, what can be used for the init blocks inside an enum class ? Are their content executed at any time?

[Alowaniak]

The val in the init block is local variable scoped to that init block. You could declare a var/val outside and then assign it in the init block if it requires some more logic

For the second question; I'm assuming the content in the init block gets executed once the enum instances gets created which is when the class is first loaded
Basically the same as with an object I would say

[victor-mntl]

Trying things, I finally get this error message. (I know Foo() has nosense, was just trying).

[victor-mntl]

Things I am finding:


• Variables declared INSIDE the init{...} block are local to the init block, not visible to the enum class neither to the different values it takes.
• init{...} content is executed when the enum instances are created. The enum instances are created when the first time a call is made to any value of that class and AT THAT TIME, it executes the code for ALL VALUES that ARE USED (if I don't use a Foo.THIRD value, Kotlin doesn't create that instance).

[victor-mntl]

enum class Foo () {
FIRST, SECOND, THIRD;
init {
println("init called for ${this.name} instance")
}
}

fun main() {
println("Testing to assign SECOND:")
val test2:Foo = Foo.SECOND
println("Testing to assign FIRST:")
val test1:Foo = Foo.FIRST
println("Testing to assign THIRD:")
val test3:Foo = Foo.THIRD
println("Testing to assign FIRST again:")
val test4:Foo = Foo.FIRST
}

Testing to assign SECOND:
init called for FIRST instance
init called for SECOND instance
init called for THIRD instance ***
Testing to assign FIRST:
Testing to assign THIRD:
Testing to assign FIRST again:

Please, observe this two appreciations:

• calls to init (= instance creations) for each value are made on the same ordinal order
• if we remove (=comment) the bold line of code I marked, the output line marked with * won't appear
So seems like Kotlin analyzes staticly the use of the different values of the enum class and optimices its instantations.

So, as conclusion I think init blocks should be avoided inside enum classes as far as possible if they refer to extern values or to values shared between various values of the same enum, as it could be problematic because the time of the calls and the number of calls to the code inside init wouldn't be as sure as a classic instantation of an 'classic' object.