Map from RawRepresentable Enum arrays

[litso]

Allow mapping from arrays of enums. For example:

enum Value: String {
  case A = "a"
  case B = "b"
  case C = "c"
}

let json: NSDictionary = ["values": ["a", "b", "c", "a"]]
let map = Mapper(JSON: json)

let values: [Value] = map.from("values")

[keith]

Thanks for adding this right when I was having a conversation about this! There's one big non obvious issue we need to deal with here. Let me pull together an example.

[keith]

So the issue here is backwards compatibility. We've already gotten bitten by this once. So the case is pretty simple, but it works like this:

Version 1 of your model:

enum Value: String {
  case A = "a"
}

let json: NSDictionary = ["values": ["a"]]

Then you update to version 2 of your model:

enum Value: String {
  case A = "a"
  case B = "b"
}

let json: NSDictionary = ["values": ["a", "b"]]

But then, if you're forcing the values on your original model, the values you're getting from the server are now incompatible (version 1):

enum Value: String {
  case A = "a"
}

let json: NSDictionary = ["values": ["a", "b"]]

I think that we need to expose this as much as possible to consumers so it makes it as difficult as possible to shoot yourself in the foot. Currently you can also have this problem with a single enum property as well, if you don't fallback to some default value.

[litso]

Hmm yes agree this is a great way to self-inflict foot wounds.
Maybe the solution is to change:

public func from<T: RawRepresentable>(field: String) throws -> [T]

..to accept a default value? So the above becomes:
public func from<T: RawRepresentable>(field: String, defaultValue value: T) throws -> [T]

?

[keith]

I think we should push this concern to the implementer instead. I think that often (like the case in my example) you won't have a sensible default value for this. And really what you'll want to do is flatMap out the invalid ones. Meaning the signature would be:

public func from<T: RawRepresentable>(field: String) throws -> [T?]

[litso]

Sounds good @keith. Would you like me to amend the PR with those changes?

[keith]

That would be fantastic!

[litso]

@keith pushed up the discussed changes.

The only caveat is that if you don't specify that you are expecting an array of optionals for example by adding flatMap to the end:

struct Test: Mappable {
   let values: [Value]
   init(map: Mapper) throws {
      self.values = try map.from("values").flatMap { $0 }
   }
}

So for example in this instance if you forgot to add the flat map:

struct Test: Mappable {
   let values: [Value]
   init(map: Mapper) throws {
      self.values = try map.from("values")
   }
}

Then this ends up getting called (and parsing fails):

public func from<T>(field: String) throws -> T

[Reflejo]

Seems like we either:

a) Add a new method

public func from<T: RawRepresentable>(field: String) throws -> [T]

or
b) We only have

public func from<T: RawRepresentable>(field: String) throws -> [T]

and we flatMap inside that fc

[keith]

I'm surprised that a function that returns [T?] would work when you tried to assign it to your [Value] array? Shouldn't that produce a compiler error?

[litso]

@keith the issue is that it is calling public func from<T>(field: String) throws -> T instead

[keith]

Ah yes. That will be going away as soon as I finish my branch of #7

[litso]

@keith i'm assuming this is on hold then until #7 is done?

[keith]

Yea sorry, I'll try to get to that soon. It's mostly done, just need some final testing

[keith]

Looping back here (a few months later than I would have liked). I have a PR up for the other change here: #59

[keith]

Thanks for getting this started! I've submitted #61 to implement this after the new changes.