Alternative type naming for sealed class subclasses

[nathnaeld]

Current Behavior

To maintain clarity, long class names may be used explicitly in the absence of an alternative short naming mechanism.

sealed class Animal {}
class WildAnimal extends Animal {}
class DomesticAnimal extends Animal {}
class AquaticAnimal extends Animal {}
class FlyingAnimal extends Animal {}

Animal someOperation() {
  final int result = apiCall();

  if (result == 1) {
    return WildAnimal();
  } else if (result == 2) {
    return AquaticAnimal();
  } else if (result == 3) {
    return FlyingAnimal();
  } else {
    return DomesticAnimal();
  }
}

void main() {
  final animal = someOperation();

  switch (animal) {
    case WildAnimal:
      print('The animal is wild.');
    case DomesticAnimal:
      print('The animal is domestic.');
    case AquaticAnimal:
      print('The animal is aquatic.');
    case FlyingAnimal:
      print('The animal is flying.');
  }
}

Proposed Feature

Introduce an alternative naming mechanism for sealed class subclasses, allowing shorter, more intuitive names while retaining the original functionality.

sealed class Animal {}

// Alternative 1
class WildAnimal extends Animal alias Wild {}
class DomesticAnimal extends Animal alias Domestic {}
class AquaticAnimal extends Animal alias Aquatic {}
class FlyingAnimal extends Animal alias Flying {}

// Alternative 2
class WildAnimal as Wild extends Animal  {}
class DomesticAnimal as Domestic extends Animal  {}
class AquaticAnimal as Aquatic extends Animal {}
class FlyingAnimal as Flying extends Animal {}

// Alternative 3
class WildAnimal, Wild extends Animal  {}
class DomesticAnimal, Domestic extends Animal  {}
class AquaticAnimal, Aquatic extends Animal {}
class FlyingAnimal, Flying extends Animal {}

Animal someOperation() {
  final int result = apiCall();

  if (result == 1 ) {
    return Animal.Wild();
  } else if (result == 2) {
    return Animal.Aquatic();
  } else if (result == 3) {
    return Animal.Flying();
  } else {
    return Animal.Domestic();
  }
}

void main() {
  final Animal animal = someOperation();

  switch (animal) {
    case Wild:
      print('The animal is wild.');
    case Domestic:
      print('The animal is domestic.');
    case Aquatic:
      print('The animal is aquatic.');
    case Flying:
      print('The animal is flying.');
  }
}

Benefits

1. Improved Readability: Short alternative names like Wild, Domestic, Aquatic, and Flying reduce verbosity and improve code clarity. They also simplify switch statements by eliminating long case names, making the code more concise, easier to read, and maintain without sacrificing clarity.
2. Scoped Names: Alternative names are scoped within the sealed class, avoiding naming conflicts.
3. Developer Convenience: Subclasses can be accessed using concise, memorable aliases (e.g., Animal.Wild), eliminating the need to recall full class names or the inheritance structure, leading to more efficient and less error-prone code.

This feature is a quality-of-life improvement that is fully backward-compatible, offering ergonomic enhancements when working with sealed classes, particularly in state management scenarios like Flutter Bloc or other hierarchical structures.

[mateusfccp]

Could be solved with #336.

[lrhn]

Agree. I'd rather have real static nested classes than any aliasing or shorthand.
Combined with "enum shorthand" (#1183), I could see

sealed class Animal {
  static class Wild extends Animal { ... }
  static class Domestic extends Animal { ... }
  ///
}

also allow

switch (someAnimal) {
  case .Wild(...): ...
  case .Domestic(...): ...
  ...
}

[mraleph]

Also somewhat related to #3021

[munificent]

I agree with @nathnaeld that not having to effectively namespace the sealed classes with their supertype name would be nice. But as @lrhn says, I think the best way to get that is through some kind of nested class support like #1183 or #3021.

I'm going to go ahead and close this because I don't think this is the specific approach we're likely to take.