Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split JSON Out of Swiftz #274

Closed
CodaFi opened this issue Nov 15, 2015 · 22 comments
Closed

Split JSON Out of Swiftz #274

CodaFi opened this issue Nov 15, 2015 · 22 comments

Comments

@CodaFi
Copy link
Member

CodaFi commented Nov 15, 2015

@mpurland's recent pull requests have made it clear to me that it would be more useful to have JSON exist outside of this framework. Because it remains the one component that doesn't interact all that much with Swiftz as a whole, and is the last thing that requires Foundation, I figure it would do just fine as a standalone framework.

Names, comments, criticisms, objections?

@pthariensflame
Copy link
Member

👍

No idea what it should be called, though…

@mpurland
Copy link
Member

I think you are right, it is the only section of Swiftz that requires Foundation and is completely separate in principle from the rest of the library. We could separate it out. I think there are a couple of paths.

  1. Separate out JSON parsing as-is into a different framework with Swiftz as a dependency. (implicitly also Swiftx and Operadics). Perhaps we could call it Swiftj?

  2. Use a separate framework like Argo for JSON parsing. There would be a migration and backwards compatibility problem with this approach.

@CodaFi
Copy link
Member Author

CodaFi commented Nov 15, 2015

I was thinking the 2nd, as we've had so much success with it in the past (see Concurrent, Focus, Swiftx). If users still wish to use Swiftx and Swiftz, they can update their cartfiles and pods as much.

@mpurland
Copy link
Member

@CodaFi To clarify, do you mean to separate the Swift JSON parsing in Swiftz into a separate framework (like you are saying with Concurrent, Focus, Swiftx, etc) or to deprecate/remove it entirely and give a migration path to users of Swiftz to use another library like Argo?

@CodaFi
Copy link
Member Author

CodaFi commented Nov 15, 2015

I mean we create our own package and keep everything within the typelift ecosystem following the models of those aforementioned frameworks, then deprecate Swiftz's stuff and put out a new point-release.

@CodaFi
Copy link
Member Author

CodaFi commented Nov 15, 2015

Also, seeing as you've probably got more edits of that code than anyone (probably even Max at this point), I think you deserve admin access to anything we create. Even to TypeLift as a whole if you're up for it.

@mpurland
Copy link
Member

@CodaFi I'm up for it, thanks. Any thoughts about the name of the new package?

@CodaFi
Copy link
Member Author

CodaFi commented Nov 15, 2015

Great!

OK, well Aeson, Jason, and JSON would be too blatant a violation of others' work. Continuing the greek trend

  • Thessalus, son of Jason
  • Tyro, father of Aeson, grandfather of Jason
  • Promachus, brother of Jason

@CodaFi
Copy link
Member Author

CodaFi commented Nov 15, 2015

Or just something with a hard J in the front.

@mpurland
Copy link
Member

I like those ideas. Tyro or Thessalus would be good. Also, we could consider Zetes (The Boreads, brothers Calais and Zetes) "They were Argonauts and played a particularly vital role in the rescue of Phineus from the harpies." since it contains a z.

@pthariensflame
Copy link
Member

Another option along the same lines would be Alcimede.

@CodaFi
Copy link
Member Author

CodaFi commented Nov 15, 2015

I like Tyro for length, Zetes for the pun, and Alcimede because she's a badass. Any more, or start narrowing?

@mpurland
Copy link
Member

I think these are good options. I also like Tyro for the length, Zetes because of the inclusion of z, and Alcimede sounds good.

@CodaFi
Copy link
Member Author

CodaFi commented Nov 15, 2015

Oh, I've always wanted to name something janeway, or in this case JWay

@pthariensflame
Copy link
Member

XD

@mpurland
Copy link
Member

Janeway would be alright. JWay would sound a little too much like a Java framework.

@CodaFi
Copy link
Member Author

CodaFi commented Nov 16, 2015

Well, @mpurland you have the rights to do whatever you like right now. Go ahead and pick a name and a make a new repository.

Would you like us to close out all the existing pull requests and try again on the new repo after it's made, or would you prefer we merge first and ask questions later?

@mpurland
Copy link
Member

@CodaFi Thanks. Yes, let's merge what is currently there (if it makes sense) and then start using the latest in master as a base. What do you think?

@CodaFi
Copy link
Member Author

CodaFi commented Nov 16, 2015

👍 Let's do it.

@mpurland
Copy link
Member

@CodaFi This is a first pass. I'll create the official repository after I can put a little more time into it. Take a look here: https://github.com/mpurland/Tyro

@mpurland
Copy link
Member

I believe it's ready to be reviewed (https://github.com/mpurland/Tyro). Let me know what you think. I've added Travis CI integration and have ~75% test code coverage so far. I'll be adding more tests later with exact tests around the same json-data as Aeson and performance tests around large json data sets.

@mpurland
Copy link
Member

⛵ See https://github.com/typelift/Tyro

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants