This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (74)
- # boot (23)
- # braid-chat (7)
- # cider (5)
- # clara (3)
- # cljsjs (17)
- # cljsrn (1)
- # clojure (105)
- # clojure-austin (9)
- # clojure-new-zealand (34)
- # clojure-poland (2)
- # clojure-russia (177)
- # clojure-uk (41)
- # clojure-ukraine (2)
- # clojurescript (130)
- # component (1)
- # core-async (2)
- # core-matrix (6)
- # cursive (7)
- # data-science (103)
- # datomic (24)
- # emacs (15)
- # funcool (4)
- # hoplon (21)
- # immutant (151)
- # ldnclj (76)
- # melbourne (1)
- # off-topic (8)
- # om (152)
- # om-next (1)
- # onyx (26)
- # parinfer (38)
- # re-frame (13)
- # reagent (14)
- # spacemacs (1)
- # vim (92)
- # yada (1)
I suppose that makes sense so long as it tracks parinfer implementation pretty closely?
I mean, I can version it independently, but I’m not sure how much sense that makes. Currently the idea is that the JVM version is basically an exact port of the original, right?
What happens when you make a change that doesn't match parinfer.js? Like a JVM speed improvement.
I think the public API and major version should probably track parinfer.js closely, but I can see situations where parinfer-jvm would have minor or patch releases that differ from parinfer.js
parinfer.py 0.7.0 is a good example of a release that only changed internals for Python-reasons: https://github.com/oakmac/parinfer.py/commit/eff391b444e6944737107d027d0abd38b2aa27a6
Want to just flag parinfer-jvm at 1.0.0 with your next release? I'm fine with that; I don't think the public API is going to change in a breaking way anytime soon
@chrisoakman: Yeah, I was thinking about that on the way home and came to the same conclusion. I’m actually going to look at changing the API to make it throw an exception on error rather than catching it and wrapping it, which is fairly idiomatic and makes the result object simpler.
the exception catching mechanism inside Parinfer isn't really an error in the classic sense of "something went wrong and I don't know how to deal with it"
it's perfectly valid (and expected) for the user to type text in Indent Mode that Parinfer simply cannot process (unbalanced quotes are the best example of this)
I don't really know what it would mean if Parinfer threw an error in those cases; whatever would be trapping that error would have to know about Parinfer internals to be able to understand or deal with it
and, if the user of the API doesn't wrap the Parinfer try in a catch, then something pretty innocent (like passing an unbalanced quote string) could theoretically blow up very high up the in stack
parinfer.js didn't use exceptions in the past; it just kept some additional boolean flags on the result object and checked them at every loop iteration
(not that that is better than the way it currently works, just an interesting observation)
It’s more idiomatic for Java libraries, though. And (checked) exceptions in Java are usually used for conditions that are expected (file not found), and runtime ones for unexpected (null pointer etc)
The exception isn’t an unknown part of the Parinfer internals, it becomes a part of the API at that point. It’s unusual to return an error object in Java libs.
> if the user of the API doesn't wrap the Parinfer try in a catch, then something pretty innocent (like passing an unbalanced quote string) could theoretically blow up very high up the in stack You’re inadvertently making the case for checked exceptions . And the same is true if you return a result object where some fields are filled in on error and others on success - if you don’t correctly check the error cases you’ll get a null pointer with the same effect.
An error like that should be a one-time event during development, too, unless the implementer never checks any error conditions either in manual testing or test cases. That’s unlikely here since there’s an established test suite.
> it's nice that the result from Parinfer is always in the same format Except that it’s not, really. There are fields that are filled in in case of error, and fields that are filled in in case of success. If you think in terms of schemas they’re really two distinct cases. Using an exception with the error fields, and a result object with the success fields is IMO cleaner and means that the fields don’t have to be nullable.
I don’t think it’s a big deal though, it’s just a little odd for Java consumers right now.
interesting discussion. i gotta admit, i’m indifferent 😉 i guess it depends on whether your goal is to be a direct port of the reference impl or be an idiomatic library in its own right. i thought the goal of parinfer-jvm was primarily the former. if it was the latter, i imagine you’d want to change other things as well, like (heaven forbid) use a stateful object with instance methods instead of static methods.
Yeah, although I think static methods in APIs are more common than error objects. Either way, I agree that the worldwide anticipated audience for this port probably approximates 2, so I’ll leave it as is right now.