[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610265#comment-16610265
]
Andy Jefferson commented on JDO-652:
------------------------------------
As I hinted at, you specified Double so java generics enforces Double, and Java
generics throws its toys out of the pram. If instead you did
{{IfElseExpression<Number> ifExpr = query.ifElseExpression(Number.class);}}
then it's fine.
You could look at updating ComparableExpression methods that take in
{code:java}
ComparableExpression<T>{code}
to take in
{code:java}
ComparableExpression<? extends T>{code}
or something similar, to get around Java generics compilation nonsense.
Since (java.lang.)String and (java.util.)Date have no subtypes then their
associated Expression has no need of generics, whereas since (java.lang.)Number
has many subtypes and so its associated Expression does have need of generics.
Further to that we have a need to enforce type precision on some methods down
to the Double/Integer/Float level, such as
{code:java}
NumericExpression<Double> avg();{code}
hence it is either have generics on NumericExpression, or have to introduce
DoubleExpression, IntegerExpression, etc, and I don't want to go there.
As for naming, the reason it is called "IfElseExpression" (as opposed to
"IfThenElse") is that all expressions in that package are using the same naming
scheme ... XXXExpression. I've no problem with it being "IfThenElseExpression",
but maybe that is what Craig meant (and not calling it "IfThenElse" without the
Expression)?
> Provision of a typesafe refactor-friendly query capability for JDOQL
> --------------------------------------------------------------------
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
> Reporter: Andy Jefferson
> Assignee: Michael Bouschen
> Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-patch-Andy.txt, JDO-652-patch3.txt,
> typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
