| 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
_______________________________________________
el-dev mailing list
el-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/el-dev