On 7/10/2014 10:37pm, Andrus Adamchik wrote:
>> Can't we parse without any ambiguity:
>>
>> exp("artist.dateOfBirth < $date", c.getTime());
>
> In case of a single parameter you are right. Good point!
In the case of multiple parameters could we just as easily pass parameters in
order for a cleaner syntax?
exp("artist.dateOfBirth < $date and artist.name = $name", c.getTime(),
"adam");
There are lots of APIs that follow this approach right back to the C printf
function.
>> // static use of 'or' seems cleaner than chaining expressions with
>> 'exp.orExp(..)'
>>> List<Painting> paintings4 = SelectQuery.query(Painting.class,
>>> or(qualifier2, qualifier3)).select(context);
>>
>> Let's see how this plays out with longer queries:
>>
>> List<Painting> paintings4 = SelectQuery.query(Painting.class,
>> and(or(qualifier2, qualifier3), qualifier4)).select(context);
>>
>> That looks a bit like reverse Polish notation. To my mind, this approach is
>> clearer:
>>
>> List<Painting> paintings4 = new
>> SelectQuery(Painting.class).or(qualifier1).or(qualifier3).and(qualifier4).select(context);
>>
>>
>> Am I misunderstanding the different approaches to this? It appears both are
>> valid with the patch you are proposing. Also,
>
> Yes both are valid. The point of the new one is that deeply nested
> expressions can not be easily built within a context of query, so you'd build
> them separately and then pass the final object to the query. So
> query.or/and(..) is sort of a final step in the qualifier assembly.
> ExpressionFactory.or/and(..) is to build the clauses you pass in there.
Fair enough. Then we'll keep both approaches as valid and possible? I'd suggest
the second syntax is the one we'd want to push as the introductory approach in
the tutorials however... it is simple and easier to understand without the
static imports.
Personally I don't see the pattern with static imports as something I'd use,
but perhaps other people would.
>> I think the use of the words "qualifier" and "expression" are confusing. We
>> use them interchangeably without much reason. Can we pick one and stick to
>> it?
>
> I thought about it it too. The original reason for 2 terms was that qualifier
> is always an expression, while expression is not always a qualifier (e.g.
> path expressions used in orderings). Not sure how to best reconcile it? To
> add to the confusion I'd even use "filter" instead of qualifier :)
Certainly 'filter' is a better word that is clearer to the users. But perhaps
we are too far down the rabbit hole now with too many classes called Expression
and too many methods already using that word. How about we keep "Expression" as
the thing which you attach to a query and use a different term in our docs for
a "path" to attach to orderings.
In your patch, the Javadocs use qualifier and expression completely
interchangeably which is confusing. Perhaps the word qualifier should go away
completely.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
