On the last lines, I meant
a or b and c -- will translate to --> a or b and c, while
(a or b) and c -- will translate to --> (a or b) and c.
So brackets only when needed
2010/1/24 Andrey Razumovsky <razumovsky.and...@gmail.com>
> 4.6.6 Operators and Operator Precedence
> The operators are listed below in order of *decreasing precedence*.
> ...
> • Logical operators:
> NOT
> AND
> OR
>
> So e.g.
> a or b and c
> equals to
> a or (b and c)
>
> Actually it's the same in any language, e.g. in Java.
> currently our translator has no notion of brackets around statements at
> all. We could insert them everywhere (like in Andreas's patch) - but it's
> cleaner insert them only when needed. So
> a or b and c -- will translate to --> a or (b and c), while
> a and b and c -- will translate to --> a and b and c.
>
> And what about jjtGetParent()?
>
> 2010/1/24 Andrus Adamchik <and...@objectstyle.org>
>
> As I said, I don't understand 'needBracket' logic.
>>
>> Per Andreas's example, the parser already does the correct grouping based
>> on user specified parentheses. So all we need to do is to eagerly place "("
>> and ")" around each conditional node. So Andreas's patch was doing the right
>> thing (of course it also needed handling of AND and NOT).
>>
>> And that's what we are already doing for SelectQuery qualifiers. Although
>> IIRC we have a "flattenning" algorithm to skip parentheses in uniformly
>> joined 3+ term conditions.. Was that the intention of 'needBracket'?.
>>
>> Andrus
>>
>>
>> On Jan 24, 2010, at 12:39 PM, Andrus Adamchik wrote:
>>
>> Where does the notion of priority come from? Logically (and from the
>>> spec) OR/AND/NOT all have the same priority.
>>>
>>> Andrus
>>>
>>> On Jan 24, 2010, at 12:02 PM, Andrey Razumovsky (JIRA) wrote:
>>>
>>> Andrey Razumovsky updated CAY-1371:
>>>> -----------------------------------
>>>>
>>>> Attachment: 1371.txt
>>>>
>>>> Patch that fixes the issue. Not committing it just yet, because I'm not
>>>> sure about patterns of expression processing. Is it correct to call
>>>> jjtGetParent() ? If so, why isn't there a method with more suitable name?
>>>>
>>>
>>>
>>>
>>
>
>
> --
> Andrey
>
--
Andrey
