[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)
