[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142108#comment-15142108
]
Renato Garcia commented on JDO-751:
-----------------------------------
{quote}
But what happens in your example if foo is a variable and is null?
{quote}
It would just filter the {{Address}} instances that have postCode {{null}}, in
a scenario that postCode is a *non*-{{Optional}}.
On the other hand if {{address}} is {{empty}}, it would have same behaviour of
nullable fields on navigation.
{quote}
Could foo also be an Optional instance?
{quote}
Yes, as long as {{postCode}} is of type {{Optional<T>}} that would fine. The
type matching should be just like the any other and in this case it should
accept {{null}}, since Java does as well, and {{Optional<T>}}, but not {{T}}.
Even though the Java compiler doesn't prevent you from assigning {{null}} to an
{{Optional}} reference it is considered bad practice or semantically wrong (it
can/should be handled by static analysis tools). So I think the same idea
should apply to the query. Therefore, while I think that {{"date == null"}}
shouldn't be the same as {{!date.isPresent()}}, considering that it can be
cumbersome to implement the difference between {{null}} and {{empty}} in some
datastores(unless you store the empty state), like RDBMS for instance, perhaps
it should be also true that querying with {{null}} on an Optional has undefined
behaviour; which is not a big deal because in practice since you shouldn't be
doing it anyway and when you are using {{Optional}} this distinction becomes
irrelevant.
{quote}
I think the shortcut looks nice, but I'm not convinced it can be implemented
without inconsistencies.
{quote}
I think the {{Optional}} deference/shortcuts are similar to what is done with
getters. Instead of writing(assuming no Optional involved):
{{person.getAddress().getPostCode() == foo}} you can write
{{person.address.postCode == foo}}, which is not consistent with the respective
Java code too, but very convenient.
The deference would only be for navigation on the filter, but on results would
still return an Optional of course. I don't see this as inconsistent but it's
definitely a special case. In my opinion it pays off to have a special
treatment (unless we come up with something better than deferencing it with
get) given that when you decide to use Optional instead of null to represent
nullability/optionality, it becomes very common pattern on your model, so
providing a special syntax makes a lot of sense.
{quote}
I also think the idea of Optional is to provide some additional semantics. If
someone is happy using the shortcuts in queries then they should probably use
the same shortcuts in Java. It also means that they are probably not interested
in the additional semantics and should probably not use Optional in the first
place. Would you agree?
{quote}
I agree in principle, however it doesn't mean that you can't have a nicer
syntax for it. I believe that the idea is that if you are using {{Optional}}
you would use a more functional style {{map/filter}} instead of calling
{{isPresent()}} and {{get()}} -- but I'm not sure how this would apply to the
query; so you kind of have the shortcuts, might not be as good as in Scala or
other JVM language with more support for functional constructs, but it is still
there.
> Support for Java8 Optional
> --------------------------
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
> Issue Type: New Feature
> Components: specification, tck
> Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages.
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this
> as a "supported persistable type"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
