[jira] [Commented] (JEXL-342) Support for Java Optional.
[ https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532656#comment-17532656 ] Hussachai Puripunpinyo commented on JEXL-342: - [~henrib] Let me put the note on the things that I had to change the visibility. It's hard for me to find it out right now. For optional, I did change Arithemtic, and we also changed getAttribute. I had to override the getAttribute function from the Interpreter for non-arithmetic context. We made it configurable because as you know we support various languages. There are many other classes that we can unwrap and I don't think that it should be part of JEXL. I feel like it's better if you can provide the callback function for the extension to override rather than putting the concrete implementation there. > Support for Java Optional. > -- > > Key: JEXL-342 > URL: https://issues.apache.org/jira/browse/JEXL-342 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Garret Wilson >Priority: Major > Fix For: Later > > > Does JEXL provide any native support for Java 8+ {{Optional<>}}? If not can > this this easily be added as some sort of plugin, or better yet can it be > added to the library? > h3. {{Optional}} Traversal > I need to create an API that works well for application developers as for > those using templates with JEXL expressions. Let's say that the {{Bar}} class > has a {{Bar.getName()}}. And the {{Foo}} class has this method: > {code:java} > Optional getBar(String barId); > {code} > In code getting the "test" foo-bar name would be like this: > {code:java} > String fooBarName=foo.getBar("test").map(Bar::getName).orElse(null); > {code} > I want the navigation across {{Optional<>}} to work just as if it were a > nullable variable. That is, I want the following JEXL expression to give the > same result as {{fooBarName}} above: > {code} > foo.bar("test").name > {code} > If {{Foo.getBar(String)}} returned a nullable rather than an {{Optional<>}}, > I think JEXL would work for this already. but the whole point of > {{Optional<>}} is that I keep nullables out of my code, so I don't want to > create inferior APIs inconsistent with the rest of my project just to work > with JEXL. > h3. {{Optional}} Getter Name > As icing on the cake, I would like to have {{Optional<>}} returning getter > discovery to recognize the {{findXXX}} pattern, as [Stephen Colebourne > suggested|https://blog.joda.org/2015/09/naming-optional-query-methods.html]. > I've been using this pattern for several years, and I really like it. Thus to > indicate that the {{Foo.getBar(String)}} "getter" doesn't return a nullable > but an {{Optional<>}}, I would name it {{Foo.findBar(String)}}, like this: > {code:java} > Optional findBar(String barId); > {code} > I would thus want the exact same JEXL expression above to still work: > {code} > foo.bar("test").name > {code} > Otherwise I'll have to forego use of modern Java constructs and make an > outdated style and less safe API just to get JEXL to work. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-342) Support for Java Optional.
[ https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532548#comment-17532548 ] Henri Biestro commented on JEXL-342: Added an OptionalArithmetic that dereferences optionals. Commit [fa3e3db|https://github.com/apache/commons-jexl/commit/fa3e3db789e85beb7bafcfa882af43a5ae5026c8] > Support for Java Optional. > -- > > Key: JEXL-342 > URL: https://issues.apache.org/jira/browse/JEXL-342 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Garret Wilson >Priority: Major > Fix For: Later > > > Does JEXL provide any native support for Java 8+ {{Optional<>}}? If not can > this this easily be added as some sort of plugin, or better yet can it be > added to the library? > h3. {{Optional}} Traversal > I need to create an API that works well for application developers as for > those using templates with JEXL expressions. Let's say that the {{Bar}} class > has a {{Bar.getName()}}. And the {{Foo}} class has this method: > {code:java} > Optional getBar(String barId); > {code} > In code getting the "test" foo-bar name would be like this: > {code:java} > String fooBarName=foo.getBar("test").map(Bar::getName).orElse(null); > {code} > I want the navigation across {{Optional<>}} to work just as if it were a > nullable variable. That is, I want the following JEXL expression to give the > same result as {{fooBarName}} above: > {code} > foo.bar("test").name > {code} > If {{Foo.getBar(String)}} returned a nullable rather than an {{Optional<>}}, > I think JEXL would work for this already. but the whole point of > {{Optional<>}} is that I keep nullables out of my code, so I don't want to > create inferior APIs inconsistent with the rest of my project just to work > with JEXL. > h3. {{Optional}} Getter Name > As icing on the cake, I would like to have {{Optional<>}} returning getter > discovery to recognize the {{findXXX}} pattern, as [Stephen Colebourne > suggested|https://blog.joda.org/2015/09/naming-optional-query-methods.html]. > I've been using this pattern for several years, and I really like it. Thus to > indicate that the {{Foo.getBar(String)}} "getter" doesn't return a nullable > but an {{Optional<>}}, I would name it {{Foo.findBar(String)}}, like this: > {code:java} > Optional findBar(String barId); > {code} > I would thus want the exact same JEXL expression above to still work: > {code} > foo.bar("test").name > {code} > Otherwise I'll have to forego use of modern Java constructs and make an > outdated style and less safe API just to get JEXL to work. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-342) Support for Java Optional.
[ https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17532276#comment-17532276 ] Henri Biestro commented on JEXL-342: [~hussachai] , you said '...changing the visibility of the functions and classes so that we can override...'. Do you have a list of those ? May be these changes can be incorporated in the main branch. Regarding Optional, did you also change the Arithmetic ? Is your solution very different from the one outlined here ? > Support for Java Optional. > -- > > Key: JEXL-342 > URL: https://issues.apache.org/jira/browse/JEXL-342 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Garret Wilson >Priority: Major > Fix For: Later > > > Does JEXL provide any native support for Java 8+ {{Optional<>}}? If not can > this this easily be added as some sort of plugin, or better yet can it be > added to the library? > h3. {{Optional}} Traversal > I need to create an API that works well for application developers as for > those using templates with JEXL expressions. Let's say that the {{Bar}} class > has a {{Bar.getName()}}. And the {{Foo}} class has this method: > {code:java} > Optional getBar(String barId); > {code} > In code getting the "test" foo-bar name would be like this: > {code:java} > String fooBarName=foo.getBar("test").map(Bar::getName).orElse(null); > {code} > I want the navigation across {{Optional<>}} to work just as if it were a > nullable variable. That is, I want the following JEXL expression to give the > same result as {{fooBarName}} above: > {code} > foo.bar("test").name > {code} > If {{Foo.getBar(String)}} returned a nullable rather than an {{Optional<>}}, > I think JEXL would work for this already. but the whole point of > {{Optional<>}} is that I keep nullables out of my code, so I don't want to > create inferior APIs inconsistent with the rest of my project just to work > with JEXL. > h3. {{Optional}} Getter Name > As icing on the cake, I would like to have {{Optional<>}} returning getter > discovery to recognize the {{findXXX}} pattern, as [Stephen Colebourne > suggested|https://blog.joda.org/2015/09/naming-optional-query-methods.html]. > I've been using this pattern for several years, and I really like it. Thus to > indicate that the {{Foo.getBar(String)}} "getter" doesn't return a nullable > but an {{Optional<>}}, I would name it {{Foo.findBar(String)}}, like this: > {code:java} > Optional findBar(String barId); > {code} > I would thus want the exact same JEXL expression above to still work: > {code} > foo.bar("test").name > {code} > Otherwise I'll have to forego use of modern Java constructs and make an > outdated style and less safe API just to get JEXL to work. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-342) Support for Java Optional.
[ https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528307#comment-17528307 ] Hussachai Puripunpinyo commented on JEXL-342: - We forked JEXL at my company and I'd say JEXL code is very extensible. We support Java Optional and other native bindings for Scala and Kotlin including JSON types in the respective languages. We rarely touch the JEXL code to make sure that we can sync the upstream when we need to. (The only thing that is unavoidable like changing the visibility of the functions and classes so that we can override). We change the language so much until it doesn't look like JEXL :) Anyway, I still think this is a useful feature. What about having extra package and it can be in a separate jar? > Support for Java Optional. > -- > > Key: JEXL-342 > URL: https://issues.apache.org/jira/browse/JEXL-342 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Garret Wilson >Priority: Major > Fix For: Later > > > Does JEXL provide any native support for Java 8+ {{Optional<>}}? If not can > this this easily be added as some sort of plugin, or better yet can it be > added to the library? > h3. {{Optional}} Traversal > I need to create an API that works well for application developers as for > those using templates with JEXL expressions. Let's say that the {{Bar}} class > has a {{Bar.getName()}}. And the {{Foo}} class has this method: > {code:java} > Optional getBar(String barId); > {code} > In code getting the "test" foo-bar name would be like this: > {code:java} > String fooBarName=foo.getBar("test").map(Bar::getName).orElse(null); > {code} > I want the navigation across {{Optional<>}} to work just as if it were a > nullable variable. That is, I want the following JEXL expression to give the > same result as {{fooBarName}} above: > {code} > foo.bar("test").name > {code} > If {{Foo.getBar(String)}} returned a nullable rather than an {{Optional<>}}, > I think JEXL would work for this already. but the whole point of > {{Optional<>}} is that I keep nullables out of my code, so I don't want to > create inferior APIs inconsistent with the rest of my project just to work > with JEXL. > h3. {{Optional}} Getter Name > As icing on the cake, I would like to have {{Optional<>}} returning getter > discovery to recognize the {{findXXX}} pattern, as [Stephen Colebourne > suggested|https://blog.joda.org/2015/09/naming-optional-query-methods.html]. > I've been using this pattern for several years, and I really like it. Thus to > indicate that the {{Foo.getBar(String)}} "getter" doesn't return a nullable > but an {{Optional<>}}, I would name it {{Foo.findBar(String)}}, like this: > {code:java} > Optional findBar(String barId); > {code} > I would thus want the exact same JEXL expression above to still work: > {code} > foo.bar("test").name > {code} > Otherwise I'll have to forego use of modern Java constructs and make an > outdated style and less safe API just to get JEXL to work. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JEXL-342) Support for Java Optional.
[ https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364888#comment-17364888 ] Henri Biestro commented on JEXL-342: Dmitri, improvements on the base code line can be made and proposed as long as they don't break compatibility and simple language philosophy. Forking was probably the right move for your use case. Anyhow, there are many ways to extend JEXL that don't require changing its code base and this feature, supporting Optional in some meaningful way, is one of them. If you look at https://github.com/apache/commons-jexl/commit/f4903cf1df0a144f61073af038806b7ae8d4f8c0 , you'll find a baseline for the described feature. It also supports automatic Reference and AtomicReference dereferencing. Garret, hoping you'll find it useful; feel free to push PRs on this code to help test and stabilise the behaviour. > Support for Java Optional. > -- > > Key: JEXL-342 > URL: https://issues.apache.org/jira/browse/JEXL-342 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Garret Wilson >Priority: Major > Fix For: Later > > > Does JEXL provide any native support for Java 8+ {{Optional<>}}? If not can > this this easily be added as some sort of plugin, or better yet can it be > added to the library? > h3. {{Optional}} Traversal > I need to create an API that works well for application developers as for > those using templates with JEXL expressions. Let's say that the {{Bar}} class > has a {{Bar.getName()}}. And the {{Foo}} class has this method: > {code:java} > Optional getBar(String barId); > {code} > In code getting the "test" foo-bar name would be like this: > {code:java} > String fooBarName=foo.getBar("test").map(Bar::getName).orElse(null); > {code} > I want the navigation across {{Optional<>}} to work just as if it were a > nullable variable. That is, I want the following JEXL expression to give the > same result as {{fooBarName}} above: > {code} > foo.bar("test").name > {code} > If {{Foo.getBar(String)}} returned a nullable rather than an {{Optional<>}}, > I think JEXL would work for this already. but the whole point of > {{Optional<>}} is that I keep nullables out of my code, so I don't want to > create inferior APIs inconsistent with the rest of my project just to work > with JEXL. > h3. {{Optional}} Getter Name > As icing on the cake, I would like to have {{Optional<>}} returning getter > discovery to recognize the {{findXXX}} pattern, as [Stephen Colebourne > suggested|https://blog.joda.org/2015/09/naming-optional-query-methods.html]. > I've been using this pattern for several years, and I really like it. Thus to > indicate that the {{Foo.getBar(String)}} "getter" doesn't return a nullable > but an {{Optional<>}}, I would name it {{Foo.findBar(String)}}, like this: > {code:java} > Optional findBar(String barId); > {code} > I would thus want the exact same JEXL expression above to still work: > {code} > foo.bar("test").name > {code} > Otherwise I'll have to forego use of modern Java constructs and make an > outdated style and less safe API just to get JEXL to work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JEXL-342) Support for Java Optional.
[ https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289743#comment-17289743 ] Dmitri Blinov commented on JEXL-342: I've made some fiddling with new features for JEXL the other day, but many of them were not accepted at that time even with Jira tasks and PRs on github, so generally this is not an easy task, it's kind of making an omelette without breaking eggs job. Nevertheless the desire to get something done, to fill the gaps between JEXL and well-accepted modern ideas in other languages (Java 8 itself to start with) brought me to idea to get a fork, so anyone interesting in evolving JEXL could look at ([link to repository|https://github.com/dmitri-blinov/commons-jexl]). I'd love to have all or any of those features to be part of the upstream one day, though as I have said before, I fully understand that not everyone would be happy to get the eggs broken. But the progress is inevitable, and for the long run choice is tough - either JEXL will evolve or stall as a project. The solution in my opinion is well known and would be to have a major version bump for some modern experimental stuff and stable version for current implementation. > Support for Java Optional. > -- > > Key: JEXL-342 > URL: https://issues.apache.org/jira/browse/JEXL-342 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Garret Wilson >Priority: Major > > Does JEXL provide any native support for Java 8+ {{Optional<>}}? If not can > this this easily be added as some sort of plugin, or better yet can it be > added to the library? > h3. {{Optional}} Traversal > I need to create an API that works well for application developers as for > those using templates with JEXL expressions. Let's say that the {{Bar}} class > has a {{Bar.getName()}}. And the {{Foo}} class has this method: > {code:java} > Optional getBar(String barId); > {code} > In code getting the "test" foo-bar name would be like this: > {code:java} > String fooBarName=foo.getBar("test").map(Bar::getName).orElse(null); > {code} > I want the navigation across {{Optional<>}} to work just as if it were a > nullable variable. That is, I want the following JEXL expression to give the > same result as {{fooBarName}} above: > {code} > foo.bar("test").name > {code} > If {{Foo.getBar(String)}} returned a nullable rather than an {{Optional<>}}, > I think JEXL would work for this already. but the whole point of > {{Optional<>}} is that I keep nullables out of my code, so I don't want to > create inferior APIs inconsistent with the rest of my project just to work > with JEXL. > h3. {{Optional}} Getter Name > As icing on the cake, I would like to have {{Optional<>}} returning getter > discovery to recognize the {{findXXX}} pattern, as [Stephen Colebourne > suggested|https://blog.joda.org/2015/09/naming-optional-query-methods.html]. > I've been using this pattern for several years, and I really like it. Thus to > indicate that the {{Foo.getBar(String)}} "getter" doesn't return a nullable > but an {{Optional<>}}, I would name it {{Foo.findBar(String)}}, like this: > {code:java} > Optional findBar(String barId); > {code} > I would thus want the exact same JEXL expression above to still work: > {code} > foo.bar("test").name > {code} > Otherwise I'll have to forego use of modern Java constructs and make an > outdated style and less safe API just to get JEXL to work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JEXL-342) Support for Java Optional.
[ https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270927#comment-17270927 ] Gary D. Gregory commented on JEXL-342: -- Evolving JEXL is fine by me. Let's see what the community thinks. PRs on GitHub are welcome. > Support for Java Optional. > -- > > Key: JEXL-342 > URL: https://issues.apache.org/jira/browse/JEXL-342 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Garret Wilson >Priority: Major > > Does JEXL provide any native support for Java 8+ {{Optional<>}}? If not can > this this easily be added as some sort of plugin, or better yet can it be > added to the library? > h3. {{Optional}} Traversal > I need to create an API that works well for application developers as for > those using templates with JEXL expressions. Let's say that the {{Bar}} class > has a {{Bar.getName()}}. And the {{Foo}} class has this method: > {code:java} > Optional getBar(String barId); > {code} > In code getting the "test" foo-bar name would be like this: > {code:java} > String fooBarName=foo.getBar("test").map(Bar::getName).orElse(null); > {code} > I want the navigation across {{Optional<>}} to work just as if it were a > nullable variable. That is, I want the following JEXL expression to give the > same result as {{fooBarName}} above: > {code} > foo.bar("test").name > {code} > If {{Foo.getBar(String)}} returned a nullable rather than an {{Optional<>}}, > I think JEXL would work for this already. but the whole point of > {{Optional<>}} is that I keep nullables out of my code, so I don't want to > create inferior APIs inconsistent with the rest of my project just to work > with JEXL. > h3. {{Optional}} Getter Name > As icing on the cake, I would like to have {{Optional<>}} returning getter > discovery to recognize the {{findXXX}} pattern, as [Stephen Colebourne > suggested|https://blog.joda.org/2015/09/naming-optional-query-methods.html]. > I've been using this pattern for several years, and I really like it. Thus to > indicate that the {{Foo.getBar(String)}} "getter" doesn't return a nullable > but an {{Optional<>}}, I would name it {{Foo.findBar(String)}}, like this: > {code:java} > Optional findBar(String barId); > {code} > I would thus want the exact same JEXL expression above to still work: > {code} > foo.bar("test").name > {code} > Otherwise I'll have to forego use of modern Java constructs and make an > outdated style and less safe API just to get JEXL to work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JEXL-342) Support for Java Optional.
[ https://issues.apache.org/jira/browse/JEXL-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270914#comment-17270914 ] Garret Wilson commented on JEXL-342: To get really wil To get really wild, we could get the Elvis operator working, too. Using the API in the description, I would want to have the following JEXL expression work equivalent to the Java code {{foo.findBar("test").map(Bar::getName).orElse("no such bar")}}: {code} foo.bar("test").name ?: "no such bar" {code} I realize that under the hood this could get pretty complicated and that the current design of JEXL may not be amenable to this, so I didn't place it in the main feature request description. But it does show the sort of native support that would be nice. In the least, recognizing the {{findXXX()}} getter pattern and turning {{Optional<>}} to a nullable by calling {{orElse(null)}} during instance tree traversal (and treating as you normally would treat a {{null}} return value to short-circuit expression evaluation) should be completely doable and likely not too much trouble. > Support for Java Optional. > -- > > Key: JEXL-342 > URL: https://issues.apache.org/jira/browse/JEXL-342 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Garret Wilson >Priority: Major > > Does JEXL provide any native support for Java 8+ {{Optional<>}}? If not can > this this easily be added as some sort of plugin, or better yet can it be > added to the library? > h3. {{Optional}} Traversal > I need to create an API that works well for application developers as for > those using templates with JEXL expressions. Let's say that the {{Bar}} class > has a {{Bar.getName()}}. And the {{Foo}} class has this method: > {code:java} > Optional getBar(String barId); > {code} > In code getting the "test" foo-bar name would be like this: > {code:java} > String fooBarName=foo.getBar("test").map(Bar::getName).orElse(null); > {code} > I want the navigation across {{Optional<>}} to work just as if it were a > nullable variable. That is, I want the following JEXL expression to give the > same result as {{fooBarName}} above: > {code} > foo.bar("test").name > {code} > If {{Foo.getBar(String)}} returned a nullable rather than an {{Optional<>}}, > I think JEXL would work for this already. but the whole point of > {{Optional<>}} is that I keep nullables out of my code, so I don't want to > create inferior APIs inconsistent with the rest of my project just to work > with JEXL. > h3. {{Optional}} Getter Name > As icing on the cake, I would like to have {{Optional<>}} returning getter > discovery to recognize the {{findXXX}} pattern, as [Stephen Colebourne > suggested|https://blog.joda.org/2015/09/naming-optional-query-methods.html]. > I've been using this pattern for several years, and I really like it. Thus to > indicate that the {{Foo.getBar(String)}} "getter" doesn't return a nullable > but an {{Optional<>}}, I would name it {{Foo.findBar(String)}}, like this: > {code:java} > Optional getBar(String barId); > {code} > I would thus want the exact same JEXL expression above to still work: > {code} > foo.bar("test").name > {code} > Otherwise I'll have to forego use of modern Java constructs and make an > outdated style and less safe API just to get JEXL to work. -- This message was sent by Atlassian Jira (v8.3.4#803005)