{"action":"created","issue":{"url":"https://api.github.com/repos/SwiftGen/SwiftGen/issues/379","repository_url":"https://api.github.com/repos/SwiftGen/SwiftGen","labels_url":"https://api.github.com/repos/SwiftGen/SwiftGen/issues/379/labels{/name}","comments_url":"https://api.github.com/repos/SwiftGen/SwiftGen/issues/379/comments","events_url":"https://api.github.com/repos/SwiftGen/SwiftGen/issues/379/events","html_url":"https://github.com/SwiftGen/SwiftGen/pull/379","id":289518561,"number":379,"title":"Feature/yaml and plist","user":{"login":"johntmcintosh","id":931283,"avatar_url":"https://avatars2.githubusercontent.com/u/931283?v=4","gravatar_id":"","url":"https://api.github.com/users/johntmcintosh","html_url":"https://github.com/johntmcintosh","followers_url":"https://api.github.com/users/johntmcintosh/followers","following_url":"https://api.github.com/users/johntmcintosh/following{/other_user}","gists_url":"https://api.github.com/users/johntmcintosh/gists{/gist_id}","starred_url":"https://api.github.com/users/johntmcintosh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/johntmcintosh/subscriptions","organizations_url":"https://api.github.com/users/johntmcintosh/orgs","repos_url":"https://api.github.com/users/johntmcintosh/repos","events_url":"https://api.github.com/users/johntmcintosh/events{/privacy}","received_events_url":"https://api.github.com/users/johntmcintosh/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-01-18T06:27:36Z","updated_at":"2018-03-30T19:29:27Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/SwiftGen/SwiftGen/pulls/379","html_url":"https://github.com/SwiftGen/SwiftGen/pull/379","diff_url":"https://github.com/SwiftGen/SwiftGen/pull/379.diff","patch_url":"https://github.com/SwiftGen/SwiftGen/pull/379.patch"},"body":"As discussed in #359, here's my take on a Yaml parser (along with a Json alias) and a Plist parser. A couple of open questions that I have based on what I've written so far:\r\n\r\n1. So far I have only written this allowing for single file input. What do you think about whether to allow multi-file input or not? If we do allow multi-file, what is your recommendation on how to group the contexts from each input file? It seems like there could be duplicate root-level keys in each input file, so we could do something like grouping them by using the input filename as the root level key in the context?\r\n2. I have not included any example templates, as all inputs are fully custom. Would it be better for us to include a sample template as a reference anyway? If so, is there any particular use-case for this that has come up frequently that might make sense to create an example template for?\r\n\r\nThe PR looks a bit noisy from adding the Yams pod to SwiftGenKit, but other than that it wasn't too bad. Let me know if it'd be helpful to break out the PR for the pods update separately so the diff is a little cleaner to review.\r\n\r\nNOTE: I have not yet added an entry to the changelog, but wanted to go ahead and push this up so I could get some eyes on it and we could finalize any specifics around terminology before I added anything there.\r\n\r\n* [ ] I've added an entry in the `CHANGELOG.md` file to explain my changes and credit myself\r\n  * [ ] Add the entry in the appropriate section (Bug Fix / New Feature / Breaking Change / Internal Change)\r\n  * [ ] Add a period and 2 spaces at the end of your short entry description\r\n  * [ ] Add links to your GitHub profile to credit yourself and to the related PR and issue after your description\r\n\r\n---\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/SwiftGen/SwiftGen/issues/comments/377603233","html_url":"https://github.com/SwiftGen/SwiftGen/pull/379#issuecomment-377603233","issue_url":"https://api.github.com/repos/SwiftGen/SwiftGen/issues/379","id":377603233,"user":{"login":"djbe","id":641356,"avatar_url":"https://avatars0.githubusercontent.com/u/641356?v=4","gravatar_id":"","url":"https://api.github.com/users/djbe","html_url":"https://github.com/djbe","followers_url":"https://api.github.com/users/djbe/followers","following_url":"https://api.github.com/users/djbe/following{/other_user}","gists_url":"https://api.github.com/users/djbe/gists{/gist_id}","starred_url":"https://api.github.com/users/djbe/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/djbe/subscriptions","organizations_url":"https://api.github.com/users/djbe/orgs","repos_url":"https://api.github.com/users/djbe/repos","events_url":"https://api.github.com/users/djbe/events{/privacy}","received_events_url":"https://api.github.com/users/djbe/received_events","type":"User","site_admin":false},"created_at":"2018-03-30T19:29:27Z","updated_at":"2018-03-30T19:29:27Z","author_association":"OWNER","body":"Right, I apologise for the inactivity here. To answer your questions:\r\n\r\n- Multiple files: we should support it, it would keep the interface in line with the other parsers. What we do there is to have a wrapper structure around each group of data. For asset catalogs, it's a `catalog` with a `name` and some `assets`. For fonts, it's `font family` with `name` and list of `fonts`. Same with the other parsers. Those names are just the filename without the extension.\r\n-  Templates: use cases are indeed too user specific to include them all as default. But we could provide a few simple default ones, such as:\r\n- one  that generates a bunch of constants from the data\r\n- one that allows for (type)safe access to the file contents. Eg.: It generates a structure that we can point to the file path, which loads the file, and has type-safe accessors for each key\r\n\r\n---------\r\n\r\nWhat I still miss from this PR, and what was discussed in some of the other issues/PRs, is to have an actual description of the data (instead of the data itself). Say I have a config file that I want to provide type-safe access to. With the PR as is, I can only generate swift code that gives me the keys and corresponding values, but no type information. I think it would be worth adding a \"info\" or \"metadata\" object to the context describing the data and (at least) the first level of properties. For example:\r\n- files: Array — list of parsed files\r\n  - name : String — the filename\r\n  - data: Array/Dictionary/Scalar — the actual data\r\n  - metadata: Dictionary — description of the data\r\n    - type: String — Type of the root object (Array, Dictionary, Int, Float, String, Bool, ...)\r\n    - properties: Array — List of metadata descriptions of each root property (if dictionary)\r\n      - ...\r\n    - element: Dictionary — Metadata description of array element (if array)\r\n\r\nAnd the repeated descriptions:\r\n- type: String — Type of the property\r\n- name: String — Property name\r\n- properties: Array — List of metadata descriptions of each root property (if dictionary)\r\n- element: Dictionary — Metadata description of array element (if array)\r\n\r\n"}}
{"actor":{"display_login":"djbe"}}