Skip to end of metadata
Go to start of metadata

The most basic usage of enum classes is implementing type-safe enums, like in Java:

enum class Direction { 
  NORTH; SOUTH; WEST; EAST 
}

As everywhere in Kotlin, one can omit semicolons if each enum constant is situated on its own line:

enum class Direction { 
  NORTH 
  SOUTH 
  WEST 
  EAST 
}
Enums are under development
See the corresponding issues.

Enums constants are objects

Since enum constants are different instances of the enum class, they can be initialized differently:

enum class Color(val rgb : Int) { 
  RED : Color(0xFF0000) 
  GREEN : Color(0x00FF00) 
  BLUE : Color(0x0000FF) 
}

Enum constants define (anonymous) classes

Each enum constant may declare its own members and override members of the enum class:

enum class ProtocolState { 
  WAITING { 
    override fun signal() = TALKING 
  } 
 
  TALKING { 
    override fun signal() = WAITING 
  } 
 
  abstract fun signal() : ProtocolState 
}

What's next

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

7 Comments

comments.show.hide

  1. Jul 20, 2011

    Alexander Kosenkov

    Maybe there a problem with

    h + separator + join(tail)

    probably, correct recursion should be written as

    h + separator + tail.join(separator)

    1. Jul 20, 2011

      Andrey Breslav

      Yes, you are right. Thanks

  2. Jul 27, 2011

    Anonymous

    "subclassing" doesn't really make sense for enums. If anything I want to "superclass" them. Normally subtyping reduces the number of values that can be used. If something has type object it can hold any value, if it has type "Person" it can only hold persons and no longer cars, strings or whatever, if it has type employee it can no longer contain all persons but only those that are employees, ...

    This is logical and makes sense. If I write a function that works with all values of type X it will work with values of a subtype of X as well. This is no longer true if you extend instead of reduce the set of possible values.

    "enum not working"

    So let's assume that you actually create a supertype not a subtype, than everything would be sound again.

    "supertyping"

    You can use BlackWhite objects where color objects are expected because I declared Color to be a supertype of BlackWhite.

    1. Jul 29, 2011

      Anonymous

      the "ouch" case imo does not justify the awkward syntax of inverting the inheritance relationship for enums.
      I think the originally proposed syntax is correct. It follows the Effective Java PECS rule:
      the ExtraOptionKeys is both a collection and a Producer, so the 'generic type' of the ExttraOptionKeyssouding must Extend.
      if an Enum is open, its methods (or logic elsewhere, such as foo() in this case) must be robust enough to handle values that not yet exist.
      The "fix" on the other hand breaks the PECS rule; and all properties / methods of  Foo are lost for clients (aka Consumers) of the Bar Enum.

  3. Jul 02, 2012

    Eugine Savin

    Does Kotlin check incomplete pattern matches on enum classes (may be only on closed enums)???

    1. Jul 02, 2012

      Andrey Breslav

      Full pattern matching is not implemented.
      If we implement it one day, we will detect incomplete patterns

  4. Dec 27, 2012

    Peter Meix

    is there something like the Java method values(), that returns a list of all enum values?

    edit: found it ... I looked at the wrong place. As in Java, it is static...