If an Entry is either an image (with name and value) or a namespace (with name and sub-entries), shouldn't we use an enum with associated values for that instead?

Like either:

enum Entry {
  case image(name: String, value: String)
  indirect case namespace(name: String, entries: [Entry])
}

Or

struct Entry {
  var name: String
  enum Content {
    case image(value: String)
    case namespace(entries: [Entry])
  }
}

Haven't used enums with associated values yet (although I've read about them). I'll look into it.

I think the first solution (a simple enum with associated values) would be easier to use than a struct with enum inside.

Using a struct with inner enum is only useful if all cases of the enum share multiple properties, like enough to want to avoid repeating each property in each enum case's associated values.
But here we only have one common property so I think it's not worth it and integrating name directly in each enum case would be easier to manipulate.

And that way you won't need dedicate inits, you can just create Entry.image(name: "foo", value: "parent/foo") and Entry.namespace(name: "parent", entries: children).

PS: Note that I'm not sure if the indirect keyword is really needed. I think so, because the case references the enum being defined, but it's worth trying without to be sure we can't avoid it.

It would be nice to add a doc-comment to this function to document the typical structure of the PLIST/JSON returned by actool, like the keys returned, how they look for image entries, for namespaced images, for namespaces themselves… Would help understand the rest of the code parsing it (especially parse(items😃)

(I know, I should have mentioned that in the other PR about actool migration ^^)

Will do.

Should probably be private (or fileprivate)?

Should probably be private (or fileprivate)?

Should probably be private (or fileprivate)?

Seems like you don't have the same indentation settings as the ones defined in the project (2-spaces indentation)?

I don't know, sometimes Xcode forgets them, or something else.

Personally I always use tabs so that's why it sometimes gets through, even though I try to be careful.

Doesn't Swift automatically bridge boolean NSNumber to Bool with as?? Especially since the AnyObject -> Any proposal got in?

I mean, we could probably do if let providesNamespace = item[AsstCatalog.providesNamespace.rawValue] as? Bool directly maybe? (At least it's worth a try)

I think this was written before the swift3 merge. Don't know, but you're right, it should be bridged.

I totally forgot to see that in the other PR about actool migration, but if you're only using the enum AssetCatalog as a way to group constants together (and never use the cases other than via their rawValue to get the String constant), I'd suggest you to use an enum with no cases, but with static let constants namespaced in the enum instead:

private enum AssetCatalogKeys {
  static let children = "children"
  static let filename = "filename"
  static let providesNamespace = "provides-namespace"
  static let root = "com.apple.actool.catalog-contents"
}

So we'd be using the enum just as some sort of way to namespace constants?

Yup. That's how I namespace all my constants in my projects now, and have been loving it!

Like I very often have stuff like this in my projects:

struct SomeModel {
  enum JSONKeys {
    static let firstname = "firstName"
    static let lastname = "lastName"
    static let dob = "dateOfBirth"
  }

  let firstname: String
  let lastname: String
  let dateOfBirth: String

  init?(json: [String: Any]) {
    guard
      let fn = json[JSONKeys.firstname] as? String,
      let ln = json[JSONKeys.lastname] as? String,
      let dob = json[JSONKeys.dob] as? String
      else { return nil }
    self.firstname = fn
    self.lastname = ln
    self.dateOfBirth = dob
  }
}

Doesn't PathKit's Path have a dedicated property to get the path string?
I mean, String(describing:) feels more intended for debug representation purposes to me, while something like path.path or path.string if it exists would feel more right (a bit like you'd use url.absoluteString)

You'd think that, wouldn't you? There isn't any public one, only internal methods unfortunately.

It does conform to CustomStringConvertible, but that's what I'm using.

Not even path.description from some CustomStringConvertible conformance?

Yeah, but what's better? String(describing: path) or path.description?

I'll create a PR in PathKit for something better, but I'll leave it up to you what we should use for now.

I think path.description feels more like a property on Path while String(describing: path), although doing the same thing, feels more like a conversion or builder to me.

indentation (from lines 17 to 26) seems wrong 😉

⚠️ tabs indentation

Why isn't the value of this generated constant "Round/Red/Apple" instead of just "Round/Apple"?
Is it because the group in the asset catalogs doesn't have provides-namespace checked, so that's normal and intentional?
In that case I'm wondering if we should create the intermediate structure struct Red if it doesn't provide namespace. I'm thinking YES (and so in this case this output is 👍 ), as otherwise the developer wouldn't have created a group in its asset catalog… but just wanted to start the discussion in case anyone had a different opinion.

This is intentional. Only namespaced folders modify the value (prefixing them with the folder's name).

I also think yes, because the structure in the catalog is there, and SwiftGen should provide an added value by offering this deeper structure. We could pass this extra structure information on to the template, although I'll have to think about how to best implement that.

👍