Fork me on GitHub

I have JVM Parinfer updated to 1.7.0, I’ll probably push it tomorrow.


I’m going to start numbering the versions to match Parinfer proper, too.


I suppose that makes sense so long as it tracks parinfer implementation pretty closely?


At the moment they’re basically identical.


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.


The idea of semver is that the public API regulates your version numbers


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

chrisoakman04:03:30 0.7.0 is a good example of a release that only changed internals for Python-reasons:


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


You are probably the only consumer of parinfer-jvm anyway 😉


@chrisoakman: actually i’m using it too 😃


@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.


@sekao: Any complaints if I do that?


hmm; I also need to give that a think


that would be different from all the other ports of Parinfer


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)


the result object returns success: false in those cases


but it's nice that the result from Parinfer is always in the same format


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


I think maybe Parinfer exceptions should be constrained to the Parinfer library


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 simple_smile. 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.


I just pushed 0.4.0 of parinfer-jvm, tracking parinfer proper 1.7.0.


This has the previewCursorScope fix.


I’ll stick with the current numbering for the moment - @sekao was having a strange problem that I haven’t had time to investigate, I’d like to fix that before pushing a 1.0.