Hi Jochen,

      Thanks for your reviewing the codes. I think you are right about the difference between Java8's Optional and the proposed Option. As Java8 has supported option pattern and Groovy will migrate to Java8, there is no need to integrate the library and DGM will be better :)

      BTW, groovy-antlr4-grammar is very hard to maintain and its performance is quite poor, so I plan to rewrite the parser and use antlr's official Java grammar file(Java.g) as the base of Groovy grammar. The former is proved efficient. If we monitor the performance from the beginning, Groovy parser will be efficient too :)

      Here is the groovy-parser project repository: https://github.com/danielsun1106/groovy-parser
      Any suggestion and help will be welcome and appreciated ;)

Cheers,
Daniel.Sun


在 2016年8月16日 下午11:31,"Jochen Theodorou [via Groovy]" <ml-node+[hidden email]>写道:<br type="attri


On 12.08.2016 17:39, daniel_sun wrote:

> Hi all,
>
>         The option
> pattern(http://www.codecommit.com/blog/scala/the-option-pattern) is very
> useful to improve the robustness of program by avoiding NPE. Scala and Rust
> have build in the
> pattern(http://www.tutorialspoint.com/scala/scala_options.htm), but Groovy
> currently is lack of it.
>..
>          In order to introduce the option pattern into Groovy, I am willing
> to contribute my project
> "groovy-option-support"(https://github.com/danielsun1106/groovy-option-support)
> to Groovy, which is also licensed under APL2. If the contribution is
> accepted, please review the code and I'll try to improve it as your
> suggestions.

thanks for the offer. Now the mean question ;) Why should we base this
on a scala style Optional instead of the Java8 Option?

Option.$new would be Optional.ofNullable, instead of checking for None
or Some you would check on Optional#isPresent().

Adding something like your $switch can be done using... well, I guess I
would be using some combination of map and orElse or maybe a simple
if-else... depends highly on the code.

So I wonder now what the difference would be between your idea and Java
Optional extended by some DGM methods... for example for groovy truth or
the iterator.

And the main differences I spot are:

* Option available under for pre Java8 as well
* Optional has better integration in the existing libraries

Considering that we now require Java7 as minimum and that we want to
change to 8 as soon as seems to be feasible, I tend not to count the
first point as negative for Optional. Especially considering that Groovy
is really anything but a "avoid null"-language.

What do you think of adding some DGM methods for Optional instead and
let us use that instead of integrating your library?

bye Jochen




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/CONTRIBUTION-groovy-option-support-tp5734616p5734693.html
To unsubscribe from [CONTRIBUTION]groovy-option-support, click here.
NAML


View this message in context: Re: [CONTRIBUTION]groovy-option-support
Sent from the Groovy Dev mailing list archive at Nabble.com.