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
Anyone working on a Java version? #348
Comments
Nope! As far as I am aware there are no other languages in any form of development outside of the existing ruby version and the golang version that I started but haven't completed. If this is something you are interested in I would be happy to provide feedback, reviews, answer questions about the definitions, etc etc. Feel free to reach out! |
Oops, I should have said this explicitly: if you are writing a package and would like it available under the |
@ppeble I agree your thoughts. |
@ppeble Yep, that would be amazing! The thing I'm trying to sort out is how to test all the versions against each other to make sure they're all outputting the right holidays. There's some weird things to sort out, because if there's a bug in one, you'd have to fix all of them. Or, at least, make a github issue for the discrepancies? I'm not sure quite yet. |
@shaqq I've had similar thoughts! My thinking on this is basically 'each language has to be responsible for itself'. We would have the central definitions and then each language repository would then just do its own thing, update on its own schedule as the maintainer(s) saw fit. This approach has the benefit of allowing for maximum flexibility...if the golang version went without an update for 6 months but the java and ruby versions were updated multiple times then that is still overall a good thing! But the downside is exactly what you laid out: it would be possible for discrepancies. One other thing that occurred to me while I was typing this: each language version doesn't need to exactly match the API methods available in the other versions! For example, the ruby repo has core extensions and that idea doesn't really apply in any way to a potential golang version. It could be that v1.0.0 of the golang version has slightly different methods but consumes the same underlying definitions. I personally think that would be just fine! I actually have a few more ideas on how we can mitigate discrepancies/issues (such as this automated test idea in the definitions repo) but honestly at this early stage simply getting a java version stood up and consuming the definitions would be a huge win. That was my goal with the golang version before my work stalled because of life commitments. I was going to worry about discrepancies only after I had multiple languages consuming them. 😄 |
@ppeble Yeah, I definitely agree that each language library should be idiomatic to their language conventions and not uniformly dogmatic. There should be some way, somehow, to output something common amongst all of them. Even if it's just a huge file that's a sequence of strings, like:
It's probably better to be something structured, like JSON or something. But as long as we're using the library code to transform the YAML definitions into something else using the library's APIs, we should be able to just compare them in a simple spec and yell if there's a diff. I'm semi-positive we can use Github Checks to make sure this works. For the Java version.... to be honest, I was just thinking about using JRuby to output a jar. But I gotta futz with it first |
@ppeble Have you been able to figure out how to do custom methods w/ the golang version? Trying to sort out in my head how we'd do it in Java.... |
I was planning on making a
holidays
package that'd work with JVM languages. Do you know of anyone working on something like that? I figured I'd ask before duplicating work.The text was updated successfully, but these errors were encountered: