Re: javac was smarter
Not sure, if Coin, Lambda & Co. are still taking any suggestions like those,
guess there would be places for them.
The "TREAT(p AS LargeProject).budget > 1000" part of Linda's query looks
like the budget property would only matter from LargeProject, even if both
had a budget property.
@Emanuel, was there a reason why you changed your Java example to:
"p.projects > 1000" not "p.budget > 1000" ?
----- Original Message -----
From: "Emmanuel Bernard" <emmanuel.bernard_at_jboss.com>
To: <linda.demichiel_at_oracle.com>
Cc: <jsr338-experts_at_jpa-spec.java.net>
Sent: Wednesday, March 09, 2011 1:21 AM
Subject: [jsr338-experts] Re: query improvements: downcasting
On 7 mars 2011, at 21:45, Linda DeMichiel wrote:
> SELECT e FROM Employee JOIN e.projects p
> WHERE TREAT(p AS LargeProject).budget > 1000 OR
> TREAT(p AS SmallProject).name LIKE "Persist%" OR
> p.description LIKE "COST OVERRUN"
This is really the use case that makes the most sense to me as the other use
cases Linda has shown seem to overlap with TYPE.
but that leads to some questions:
1. if both LargeProject and SmallProject have a budget property, do we
return all Projects.budget > 1000? Or is the query more like
SELECT e FROM Employee JOIN e.projects p
WHERE ( TYPE(p) = LargeProject AND p.budget > 1000) OR
(TYPE(p) = SmallProject AND p.name LIKE "Persist%" ) OR
p.description LIKE "COST OVERRUN"
For reference the idiom in Java is
(p instanceof LargeProject && ( (LargeProject) p).projects > 1000) ||
(p instanceof SmallProject && isLike( ((SmallProject) p).name,
"Persist%" ) ) ||
isLike(p.description, "COST OVERRUN") //evaluates to true all the time?
And assuming javac was smarter we could do
(p instanceof LargeProject) && p.projects > 1000) ||
(p instanceof SmallProject) && isLike( p.name, "Persist%" ) ||
isLike(p.description, "COST OVERRUN")
2. if LargeProject does not have a budget property, what happens?