[jira] [Commented] (SOLR-13658) Discuss adding the new "var" construct to the forbidden API list.
[ https://issues.apache.org/jira/browse/SOLR-13658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896139#comment-16896139 ] Martin Grigorov commented on SOLR-13658: Hi [~erickerickson], You didn't provide full snippets so I might have done something in a different way but the following code compiles and runs fine: {code:java} import java.util.Map; public class Solr13658 { public static void main(String[] args) { // with var var kidding = getComplex(); var blivet = kidding.get("one"); var blah = kidding.get("two").get(2); blah = 55; System.err.println("blah: " + blah); // without var Map> kidding1 = getComplex(); Map blivet1 = kidding1.get("one"); Integer blah1 = kidding1.get("two").get(2); blah1 = 55; System.err.println("blah1: " + blah1); } private static Map> getComplex() { return Map.of( "one", Map.of("1", 1, "11", 11, "111", 111), "two", Map.of("2", 2, "22", 22, "222", 222) ); } } {code} and it prints : {code:java} blah: 55 blah1: 55 {code} in both cases _blah_s types are java.lang.Integer > Discuss adding the new "var" construct to the forbidden API list. > - > > Key: SOLR-13658 > URL: https://issues.apache.org/jira/browse/SOLR-13658 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > Personally, I'm strongly against allowing the "var" construct in Lucene/Solr > code. I think it's a wonderful opportunity to introduce bugs that won't be > found until runtime as well as making maintainence significantly harder. I > don't even think for a project like Solr it would save any time overall... > So let's discuss this ahead of time and see if we can reach a consensus. I'll > start the discussion off: > My baseline argument is that for a large complex project, especially ones > with many different people coding, I want the compiler to give me all the > help possible. And the "var" construct takes away some of that help. > I’ve seen this argument go around at least 4 times in my career. The argument > that “it takes longer to write if you have to type all this stuff” is bogus. > Last I knew, 80% of the time spent is in maintaining/reading it. So the > argument “I can write faster” means I can save some fraction of the 20% of > the time writing the original code but spend many times that figuring out > what the code is actually doing the other 80% of the time. > The IDE makes _writing_ this slightly faster, admittedly. > {code:java} > Whatever what = new Whatever(); > var kidding = what.getComplex(); > var blivet = kidding.get("stuff"); > {code} > But once that’s done, if I’m reading the code again I don't have any clue what > {code:java} > kidding or blivet > {code} > are. Here's the signature for getComplex: > {code:java} > Map> getComplex() > {code} > I have to go over to the definition (which I admit is easier than it used to > be in the bad old days, but still) to find out. > HERE'S THE PART I REALLY OBJECT TO! > The above I could probably live with, maybe we could get the InteliJ > developers and see if they can make hover show the inference. What I will > kick and scream about is introducing bugs that are not found until runtime. > Even this obvious stupidity fails with a ClassCastException: > {code:java} > var corny = new TreeMap(); > corny.put("one", "two"); > corny.get(1); > {code} > But it's much worse when using classes from somewhere else. For instance, > change the underlying class in the first example to return > {code:java} > Map>{code} > . > This code that used to work now throws an error, _but it compiles_. > {code:java} > var kidding = what.getComplex(); > var blivet = kidding.get("stuff"); > var blah = kidding.get("stuff").get(1); // generates ClassCastException: > class java.lang.String cannot be cast to class java.lang.Integer > {code} > So in order to save some time writing (that I claim will be lost multiple > times over when maintaining the code) we'll introduce run-time errors that > will take a bunch _more_ time to figure out, and won’t be found during unit > tests unless and until we have complete code coverage. > If there's a way to insure that this kind of thing can't get into the code > and we implement that, I could be persuaded, but let's make that an explicit > requirement (and find a suitable task for the build system, precommit or > whatever). > The floor is open... -- This message was sent by Atlassian JIRA (v7.6.14#76016) -
[jira] [Commented] (LUCENE-8362) Add DocValue support for RangeFields
[ https://issues.apache.org/jira/browse/LUCENE-8362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16851628#comment-16851628 ] Martin Grigorov commented on LUCENE-8362: - [~atris] Off Topic: Why do you prefer working with patches ? It would be much more convenient to comment on your changes in GitHub Pull Request UI. One reason I can think of is if you don't have an account at GitHub and you don't want to create one. Patches are fine! But with a PR I think more people may join the review. > Add DocValue support for RangeFields > - > > Key: LUCENE-8362 > URL: https://issues.apache.org/jira/browse/LUCENE-8362 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Nicholas Knize >Priority: Minor > Attachments: LUCENE-8362-approach2.patch, LUCENE-8362.patch, > LUCENE-8362.patch, LUCENE-8362.patch > > > I'm opening this issue to discuss adding DocValue support to > {{\{Int|Long|Float|Double\}Range}} field types. Since existing numeric range > fields already provide the methods for encoding ranges as a byte array I > think this could be as simple as adding syntactic sugar to existing range > fields that simply build an instance of {{BinaryDocValues}} using that same > encoding. I'm envisioning something like > {{doc.add(IntRange.newDocValuesField("intDV", 100)}} But I'd like to solicit > other ideas or potential drawbacks to this approach. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840508#comment-16840508 ] Martin Grigorov commented on SOLR-13452: OK. I just wanted to mention it since you just started on this migration (Ant -> Gradle). > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840069#comment-16840069 ] Martin Grigorov commented on SOLR-13452: Hi. Have you considered using the Gradle Kotlin dialect instead of the Groovy one ? I am not a Gradle person myself but from what I've read it is more type-safe. Recently one of the Groovy/Gradle devs tried to introduce Kotlin dialect to Apache Groovy project (and soon after he decided to leave Groovy). This says a lot! > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org