L-shaped enums

Using Swift
1

for lack of a better term, i have a lot of “L-shaped” enums that have some varying payload types, and some common payload types.

here’s an example:

extension ServerDelegate
{
    enum Request:Sendable
    {
        case get    (Get, EventLoopPromise<ServerResponse>)
        case post   (Post, EventLoopPromise<ServerResponse>)
        case delete (Delete, EventLoopPromise<ServerResponse>)
    }
}
extension ServerDelegate.Request
{
    enum Get { ... }
    enum Post { ... }
    enum Delete { ... }
}

there are problems with this layout:

  • hard to access the common field (EventLoopPromise<ServerResponse>) without switch-ing on the enum

  • hard to switch on the actual variant payload because you have to _-ignore the common fields

there is an obvious refactor here, which is lift the variant payload to another nested type:

extension ServerDelegate
{
    struct Request:Sendable
    {
        let operation:Operation
        let promise:EventLoopPromise<ServerResponse>
    }
}
extension ServerDelegate.Request
{
    enum Operation:Sendable
    {
        case get    (Get)
        case post   (Post)
        case delete (Delete)
    }
}
extension ServerDelegate.Request.Operation
{
    enum Get { ... }
    enum Post { ... }
    enum Delete { ... }
}

but this feels like a lot of nesting and a lot of (excessive?) type structure proportional to how complex the thing i am trying to model is. and the ServerDelegate.Request.Operation.Get, ServerDelegate.Request.Operation.Post, etc. enums may themselves have yet more nested structure.

what are our alternatives?

2

I'm curious what feels excessive to you about this latter option, nesting aside. It seems to me to quite directly model a type which contains a common payload and one of several variant payloads.

In any case, another reshaping I can see (starting from your first snippet) would be to push the EventLoopPromise down into each of the variant payloads, and then provide a convenience promise getter on the Request enum so that the switching only has to be done in one spot, and everywhere else you can access request.promise directly.

2 Likes
3

there are a lot of namespace dots to type, and a lot of concentric .init(.init(.init(.init( ... )))s to scan when reading code that traffics in this stuff.

the difficulty with pushing the EventLoopPromise into the variant types is that the promise value has to be passed along by every init layer, and the initializers already have lots of parameters. moreover, many of the initializers are failable (and creating a promise is an expensive operation), so i want the initialization of ServerDelegate.Request.Operation.Get, etc. to succeed first before asking the event loop group to mint a new EventLoopPromise.

4

Well, the namespace dots are a result of the nesting which isn't really fundamental to the type structure here. It also seems reasonable to provide convenience APIs to deal with some of the .init soup, e.g.:

extension Request {
  static func get(url: URL, params: [String: String], mintPromise: () -> EventLoopPromise) -> Self { ... }
}
3 Likes
5

I love writing that as it requires no thinking and very fast to type due to autocomplete. And then I almost always regret writing that when it comes to reading.

1 Like
6

For clients who adopt the API from the example in your original post, might they be required to ultimately switch over the cases such as


// MyMiddleWare.swift

func routeRequestOperation(request: ServerDelegate.Request.Operation) { 
switch request {….}
}

Assuming ServerDelegate is exposed in some sort of API / library / framework, if I’m a client with client code that looks like this, it’s up to me to have a default case right? Assuming that later on it may become likely that your API introduces a new request type, which my casing must address?

It makes me wonder if enum and the proposed nesting is the right approach to this family of problems.

For example if a case was removed, and consumer side didn’t have a default case, this would break the consumer project. Same if a case was added…

However if this were a protocol, the deletes might be safe but the additional functionality is likely not to be safe, assuming that someone could be implementing the protocol on their own (adding functionality requirements and constraints = breaking everyone who currently doesn’t conform to that new set of requirements). Deleting a requirement on the other hand seems safe but is still risky….

If it was a class, assuming no inheritance, I think that additional behavior being added is fine in all cases however deletes are not necessarily safe.

I think that what I’m getting at is:
Is enum the right type “all of the way down” ? Starting with enum casing on Request and into Operation etc. Do the expectations of the type hold continuously over all of those nested sets (nested cases)

Ultimately I think that we end up with layers of assumptions based on the underlying types that have been chosen to represent each layer. Be it a struct or nested enum or adoptable protocol etc each type offers some way to constraint or enhance the expression of the problem. And it seems natural as well as understandable to question if enum nesting is appropriate for representing this problem.

I do think it’s fine to nest the enums but it does also depend on if the type can hold safely across all of the intended behaviors for the APi

7

What about this variant?

struct Request: Sendable {
  let promise: EventLoopPromise<ServerResponse>
  let method: Method

  enum Method: Sendable {
    case get(Get)
    case post(Post)
    case delete(Delete)
  }
}