I always thought the urge to replace switches with objects was fashionably bad advice.

I get that the object literal approach feels more functional, and that forgotten break statements will cause havoc tho.

Seems like a safeswitch construct is in order, that does not allow dropthrough. something like:

  safeswitch(s) {
    case 'alpha':
      calc(alpha(x), 2);
    case 'beta':
      calc(beta(x), beta(x*x));
  } else {
    // default case here
    calc(x);
  }

alternatively, switch could be modified so that passthrough is not the default, and so, instead of a break statement one would use a passthrough statement to enable that behavior (opt in instead of opt out)

What are the implications of this? What could go wrong outside of runtime errors?

When I've used this pattern in the past I've used a reusable 'getter' object which implements `hasOwnProperty` on itself for the sake of being sure I'm getting only the stuff I want. But it's not quite as concise as what's shown in the example, apart from getting the default internally rather than externally using ||.

I didn't do this for security though, I did it for sanity - I don't want to get false positives when accessing, and the prototype has a ton of properties.