Hi all,
The new parser support defining custom operator now. The initial
implementation is on the customOperator branch of
groovy-parser(https://github.com/danielsun1106/groovy-parser/tree/customOperator).
Some examples can be found at
https://github.com/danielsun1106/groovy
This sounds a cool feature for DSL writers. What characters are eligible
for custom operators?
Cheers,
Paolo
On Sun, Oct 30, 2016 at 8:02 AM, 孙 岚 wrote:
> Hi all,
>
> The new parser support defining custom operator now. The initial
> implementation is on the customOperator branch of
I'm -1 on adding custom operators. We always said we wouldn't fall into the
same trap as C++ or Scala, but instead allow overriding existing operators.
Le 30 oct. 2016 10:03, "Paolo Di Tommaso" a
écrit :
> This sounds a cool feature for DSL writers. What characters are eligible
> for custom oper
Hi Cédric
> We always said we wouldn't fall into the same trap as C++ or Scala, but
> instead allow overriding existing operators.
Could you please expain the trap in details? Thanks in advance :)
BTW, I adjusted the priority of custom operators to avoid parentheses in
most cases.
https://githu
Hi Paolo,
Here are some example code. As you see, the special character(`) is
required to define the custom operator:
// Custom operators should be declared first, then use.
// It can be declared in the class or script, but it must be declared
static.
class A {
static "`>?`"(int a, int b)
Hi Daniel,
I haven't had realised the need of the backtick characters to define and
use custom operators. Still useful though much less *sexy* IMO.
Cheers,
Paolo
On Sun, Oct 30, 2016 at 10:30 AM, Daniel.Sun
wrote:
> Hi Paolo,
>
> Here are some example code. As you see, the special charac
Hi Paolo,
There are some limitations when we use antlr to define grammar, so the
backticks are used to distinguish with other operators.
I saw an answer from Jochen(shown as follow), so I tryied to add this
experimental feature
"We always wanted the ability to define an operator t
Hi Jochen,
I create JIRA issue
GROOVY-7983(https://issues.apache.org/jira/browse/GROOVY-7983) to track the
issue.
BTW, the code in the email should be corrected as follow:
def a = new int[2][]
def b = new int[2][][]
assert a == b // expect faling
Cheers,
Daniel.Sun
--
View this me
On 30.10.2016 11:07, Daniel.Sun wrote:
Hi Paolo,
There are some limitations when we use antlr to define grammar, so the
backticks are used to distinguish with other operators.
I saw an answer from Jochen(shown as follow), so I tryied to add this
experimental feature
"We alway
What if we look at this as a special kind of method call: in-fix method calls?
Maarten
On October 30, 2016 2:08:07 PM "Daniel.Sun" wrote:
Hi Paolo,
There are some limitations when we use antlr to define grammar, so the
backticks are used to distinguish with other operators.
I saw
Hi Jochen,
Thanks for your explaining the traps of custom operator in Groovy :)
The experimental code is on the customOperator branch, which will not
be merged to master ;)
Cheers,
Daniel.Sun
--
View this message in context:
http://groovy.329449.n5.nabble.com/Custom-operator-for-Gr
The logic of custom operator is impelemented in a method, so the custom
operator is accually method call. The feature will not be added to Groovy,
so forget it ;-)
Cheers,
Daniel.Sun
--
View this message in context:
http://groovy.329449.n5.nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736
Hi Jochen,
I'll set aside more time on your new idea ;)
Cheers,
Daniel.Sun
在 "Jochen Theodorou [via Groovy]"
,2016年10月30日 下午8:16写道:
On 30.10.2016 11:07, Daniel.Sun wrote:
> Hi Paolo,
>
> There are some limitations when we use antlr to define grammar, so the
> backticks are used
On Sun, 2016-10-30 at 10:06 +0100, Cédric Champeau wrote:
> I'm -1 on adding custom operators. We always said we wouldn't fall
> into the
> same trap as C++ or Scala, but instead allow overriding existing
> operators.
I like custom operators as in Algol-68 and Scala. It is just that some
Scala cod
On 30.10.2016 18:43, Russel Winder wrote:
On Sun, 2016-10-30 at 10:06 +0100, Cédric Champeau wrote:
I'm -1 on adding custom operators. We always said we wouldn't fall
into the
same trap as C++ or Scala, but instead allow overriding existing
operators.
I like custom operators as in Algol-68 and
15 matches
Mail list logo