[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [el-dev] Question about the new OptionalELResolver
|
On 09/02/2024 17:33, Paul Nicolucci via el-dev wrote:
Hey Mark,
To clarify your question, are you asking "What if a return value is
*not* expected?" If that's not the case can you provide an example?
I'll try and re-phrase. What do we do when a return value is expected
but the Optional is empty. Something like:
<sometag ... value="${bean.optionalThing.doSomething(input1,input2)}" />
The only choices I see are return null or throw an exception. Throwing
rather defeats the point of using an Optional so I think we have to
return null.
Do we coerce null to the expected type for the return value? I think we
have to for consistency.
If all of the above is acceptable then I think we have all we require to
implement this. If there is something about the above that folks don't
like then I think we have to leave the implementation as is.
I have no objections to an implementation along the above lines on the
basis that use of the OptionalELResolver is optional.
Mark
Regards,
Paul Nicolucci
On Thu, Feb 8, 2024 at 4:03 AM Mark Thomas via el-dev
<el-dev@xxxxxxxxxxx <mailto:el-dev@xxxxxxxxxxx>> wrote:
On 08/02/2024 00:26, Paul Nicolucci via el-dev wrote:
> Hi,
>
> I've been testing the OptionalELResolver added in:
> https://github.com/jakartaee/expression-language/issues/176
<https://github.com/jakartaee/expression-language/issues/176>
> <https://github.com/jakartaee/expression-language/issues/176
<https://github.com/jakartaee/expression-language/issues/176>>. The
> initially reported problem does look to be resolved. For example an
> expression of the form:
> "|domainObject.optionalProperty.requiredProperty|" works. However, I
> noticed that an expression trying to invoke a method on the class of
> optionalProperty does not work:
> |"domainObject.optionalProperty.someMethod()".|
> |
> |
> |Was this the intention of the OptionalELResolver or was it an
oversight
> that we should address?
Somewhere in the middle I think. The initial report was focused on
properties and the current behavior - including method invocation - is
as per the updated spec and Javadoc. That said, it makes sense to me to
do something about this if we can.
We need to decide what the expected behavior is for method invocation.
When Optional.isPresent() is true this is easy. Call the method.
What about when Optional.isEmpty() is true? NO-OP? What if a return
value is expected? null?
Mark
_______________________________________________
el-dev mailing list
el-dev@xxxxxxxxxxx <mailto:el-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/el-dev
<https://www.eclipse.org/mailman/listinfo/el-dev>
_______________________________________________
el-dev mailing list
el-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/el-dev
