I too would be interested in thoughts from anyone who has used
Ruby/Smalltalk a bit more extensively.
But generally, there is certainly more that we could potentially do. We
could do various kinds of mapping during compilation of Groovy source since
we have the names at hand - there is the issue
Because many people do not like the feature, it will not be implemented for
the time being util we reach a consensus.
P.S. It is actually a poll.
Cheers,
Daniel.Sun
--
View this message in context:
This is a feature I could see myself using immediately, so +1 from my side.
Maybe call it "Intersection Types" or "Common Denominator Types", to
seperate it from much more complex type pattern matching support ?
Daniel Sun schrieb am So., 23. Juli 2017, 00:28:
> Hi
I agree with Paul.
-1
p
On Sun, Jul 23, 2017 at 1:50 AM, Paul King wrote:
> I would be leaning towards -1 without further justification. Even though I
> don't think we want to rush into union types in Groovy, wouldn't this
> syntax rule out us having it down the track?
>
Any chance to see this PR merged in future Groovy release?
https://github.com/apache/groovy/pull/566
p
On Sun, Jul 23, 2017 at 3:00 PM, Daniel Sun wrote:
> According to the original plan, the Parrot parser will be the default
> parser for Groovy 3.0.0 eventually. But
According to the original plan, the Parrot parser will be the default parser
for Groovy 3.0.0 eventually. But currently about 20 tests(e.g. different error
messages) fail when setting Parrot as default, so we will try our best to fix
them all before releasing GA version.
Cheers,
Daniel.Sun
On Sun, 2017-07-23 at 04:55 -0700, Daniel Sun wrote:
> Looking forward to 2.6.0 and 3.0.0, which contains the Parrot parser
> providing many new features :)
>
> p.s. use -Dgroovy.antlr4=true to enable the Parrot parser
>
Will the new parser not be the default in Groovy 3?
--
Russel.
I usually just take what the newest Groovy release gives us - but now I am
curious: Where are the new features for 3.0 listed ? Groovy has no roadmap,
future outlook etc on the official webpage as far as I know ?
I am of course still very much interested in any feature that solves the
Hi Jochen,
As you said, it is actually union overloads. Fully supporting union type
is a big task. So I did not propose union type defination etc. for the time
being ;)
Cheers,
Daniel.Sun
--
View this message in context:
Union types (Sum types, really) shine when used with pattern matching and
exhaustion check.
This is not provided by this proposal.
Without that, there are already a number of ways to encode them in Groovy.
-1
Dierk
sent from:mobile
> Am 23.07.2017 um 02:13 schrieb MG :
10 matches
Mail list logo