You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Daniel Sun <re...@hotmail.com> on 2017/07/22 22:28:07 UTC
[VOTE]About the Union Type for method/constructor declaration
Hi all,
I've been thinking about Union Type for method/constructor
declaration. It is similar to multi-catch in try-catch statement, e.g.
class UnionTypeSample {
public UnionTypeSample(A|B|C p) {
// do something
}
def m(D|E p) {
// do something
}
}
Groovy will translate the above code into the following code, which is
also the same way how multi-catch is handled.
class UnionTypeSample {
public UnionTypeSample(A p) {
// do something
}
public UnionTypeSample(B p) {
// do something
}
public UnionTypeSample(C p) {
// do something
}
def m(D p) {
// do something
}
def m(E p) {
// do something
}
}
Any thoughts?
----------------------------------
[+1] I like it
[ 0] Not bad
[-1] I do not like it
----------------------------------
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-About-the-Union-Type-for-method-constructor-declaration-tp5742265.html
Sent from the Groovy Users mailing list archive at Nabble.com.
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Dierk König <di...@canoo.com>.
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 <mg...@arscreat.com>:
>
> Since this feature would have been helpful to me on several occasions (avoiding to have to introduce an interface or go dynamic) I would tentatively have said +1.
> Tentatively, because I am at the same time worried that a feature like that could prevent framework developers from introducing a meaningful interface hierarchy, over time possibly leading to code like
> void doGenericStuff(DeviceManager|VerySpecializedClassWithLongName|TautologicalFluxCompensatorMatrixElement|KungFooMaster x) { ... }
> On the other hand, IDE refactoring support could allow for automatic extraction of a shared functionality interface between the given classes here...
>
> I would also have thought of the exact same syntax - can you explain why you think it would break future extensions, Paul ?
> mg
>
>> On 23.07.2017 01:50, 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?
>>
>> Cheers, Paul.
>>
>>
>>> On Sun, Jul 23, 2017 at 8:28 AM, Daniel Sun <re...@hotmail.com> wrote:
>>> Hi all,
>>>
>>> I've been thinking about Union Type for method/constructor
>>> declaration. It is similar to multi-catch in try-catch statement, e.g.
>>>
>>> class UnionTypeSample {
>>> public UnionTypeSample(A|B|C p) {
>>> // do something
>>> }
>>>
>>> def m(D|E p) {
>>> // do something
>>> }
>>> }
>>>
>>> Groovy will translate the above code into the following code, which is
>>> also the same way how multi-catch is handled.
>>>
>>> class UnionTypeSample {
>>> public UnionTypeSample(A p) {
>>> // do something
>>> }
>>>
>>> public UnionTypeSample(B p) {
>>> // do something
>>> }
>>>
>>> public UnionTypeSample(C p) {
>>> // do something
>>> }
>>>
>>> def m(D p) {
>>> // do something
>>> }
>>>
>>> def m(E p) {
>>> // do something
>>> }
>>> }
>>>
>>> Any thoughts?
>>> ----------------------------------
>>> [+1] I like it
>>> [ 0] Not bad
>>> [-1] I do not like it
>>> ----------------------------------
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>> --
>>> View this message in context: http://groovy.329449.n5.nabble.com/VOTE-About-the-Union-Type-for-method-constructor-declaration-tp5742265.html
>>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>
>
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by MG <mg...@arscreat.com>.
Since this feature would have been helpful to me on several occasions
(avoiding to have to introduce an interface or go dynamic) I would
tentatively have said +1.
Tentatively, because I am at the same time worried that a feature like
that could prevent framework developers from introducing a meaningful
interface hierarchy, over time possibly leading to code like
void
doGenericStuff(DeviceManager|VerySpecializedClassWithLongName|TautologicalFluxCompensatorMatrixElement|KungFooMaster
x) { ... }
On the other hand, IDE refactoring support could allow for automatic
extraction of a shared functionality interface between the given classes
here...
I would also have thought of the exact same syntax - can you explain why
you think it would break future extensions, Paul ?
mg
On 23.07.2017 01:50, 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?
>
> Cheers, Paul.
>
>
> On Sun, Jul 23, 2017 at 8:28 AM, Daniel Sun <realbluesun@hotmail.com
> <ma...@hotmail.com>> wrote:
>
> Hi all,
>
> I've been thinking about Union Type for method/constructor
> declaration. It is similar to multi-catch in try-catch statement, e.g.
>
> class UnionTypeSample {
> public UnionTypeSample(A|B|C p) {
> // do something
> }
>
> def m(D|E p) {
> // do something
> }
> }
>
> Groovy will translate the above code into the following
> code, which is
> also the same way how multi-catch is handled.
>
> class UnionTypeSample {
> public UnionTypeSample(A p) {
> // do something
> }
>
> public UnionTypeSample(B p) {
> // do something
> }
>
> public UnionTypeSample(C p) {
> // do something
> }
>
> def m(D p) {
> // do something
> }
>
> def m(E p) {
> // do something
> }
> }
>
> Any thoughts?
> ----------------------------------
> [+1] I like it
> [ 0] Not bad
> [-1] I do not like it
> ----------------------------------
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/VOTE-About-the-Union-Type-for-method-constructor-declaration-tp5742265.html
> <http://groovy.329449.n5.nabble.com/VOTE-About-the-Union-Type-for-method-constructor-declaration-tp5742265.html>
> Sent from the Groovy Users mailing list archive at Nabble.com.
>
>
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Guillaume Laforge <gl...@gmail.com>.
On Mon, Jul 24, 2017 at 10:04 AM, Jochen Theodorou <bl...@gmx.org>
wrote:
>
> On 23.07.2017 17:21, Guillaume Laforge wrote:
> [...]
>
>> Speaking of pattern matching, there's Brian Goetz' proposal here, for
>> pattern matching for Java:
>> http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html
>> We should also avoid offering a different syntax as to what might come
>> up in the JDK later on, to avoid having two distinct syntaxes for the
>> same thing.
>> (although this proposal doesn't cover union types per se, it's something
>> to factor in, in our decisions)
>>
>
> I see one possible influence depending if we can declare a sum type or
> not. Because if you can really declare one (and I really think you will
> want to do that), you will potentially use it in a switch-case. That will
> open a lot of problems
>
Indeed, we'd certainly want to have it in switch / case, good point.
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Jochen Theodorou <bl...@gmx.org>.
On 23.07.2017 17:21, Guillaume Laforge wrote:
[...]
> Speaking of pattern matching, there's Brian Goetz' proposal here, for
> pattern matching for Java:
> http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html
> We should also avoid offering a different syntax as to what might come
> up in the JDK later on, to avoid having two distinct syntaxes for the
> same thing.
> (although this proposal doesn't cover union types per se, it's something
> to factor in, in our decisions)
I see one possible influence depending if we can declare a sum type or
not. Because if you can really declare one (and I really think you will
want to do that), you will potentially use it in a switch-case. That
will open a lot of problems
bye Jochen
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Guillaume Laforge <gl...@gmail.com>.
Instead of going straight to a vote, let's discuss what we would like such
a feature to cover.
Then, once we reach a good level of consensus on what we want to achieve,
then we can launch a vote.
On my side, I'm very interested in this idea.
For example, Ceylon seemed to me to have a nice coverage of this aspect.
But I'd like this feature in Groovy to work also nicely with everything,
including our type inference (with static typing and static compilation).
And depending on what we want to do with a potential pattern matching
approach, it should also work with that.
Speaking of pattern matching, there's Brian Goetz' proposal here, for
pattern matching for Java:
http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html
We should also avoid offering a different syntax as to what might come up
in the JDK later on, to avoid having two distinct syntaxes for the same
thing.
(although this proposal doesn't cover union types per se, it's something to
factor in, in our decisions)
Guillaume
On Sun, Jul 23, 2017 at 5:13 PM, Paolo Di Tommaso <paolo.ditommaso@gmail.com
> wrote:
> I agree with Paul.
>
> -1
>
>
> p
>
> On Sun, Jul 23, 2017 at 1:50 AM, Paul King <pa...@asert.com.au> 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?
>>
>> Cheers, Paul.
>>
>>
>> On Sun, Jul 23, 2017 at 8:28 AM, Daniel Sun <re...@hotmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I've been thinking about Union Type for method/constructor
>>> declaration. It is similar to multi-catch in try-catch statement, e.g.
>>>
>>> class UnionTypeSample {
>>> public UnionTypeSample(A|B|C p) {
>>> // do something
>>> }
>>>
>>> def m(D|E p) {
>>> // do something
>>> }
>>> }
>>>
>>> Groovy will translate the above code into the following code,
>>> which is
>>> also the same way how multi-catch is handled.
>>>
>>> class UnionTypeSample {
>>> public UnionTypeSample(A p) {
>>> // do something
>>> }
>>>
>>> public UnionTypeSample(B p) {
>>> // do something
>>> }
>>>
>>> public UnionTypeSample(C p) {
>>> // do something
>>> }
>>>
>>> def m(D p) {
>>> // do something
>>> }
>>>
>>> def m(E p) {
>>> // do something
>>> }
>>> }
>>>
>>> Any thoughts?
>>> ----------------------------------
>>> [+1] I like it
>>> [ 0] Not bad
>>> [-1] I do not like it
>>> ----------------------------------
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>> --
>>> View this message in context: http://groovy.329449.n5.nabble
>>> .com/VOTE-About-the-Union-Type-for-method-constructor-declar
>>> ation-tp5742265.html
>>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>>
>>
>>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Paolo Di Tommaso <pa...@gmail.com>.
I agree with Paul.
-1
p
On Sun, Jul 23, 2017 at 1:50 AM, Paul King <pa...@asert.com.au> 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?
>
> Cheers, Paul.
>
>
> On Sun, Jul 23, 2017 at 8:28 AM, Daniel Sun <re...@hotmail.com>
> wrote:
>
>> Hi all,
>>
>> I've been thinking about Union Type for method/constructor
>> declaration. It is similar to multi-catch in try-catch statement, e.g.
>>
>> class UnionTypeSample {
>> public UnionTypeSample(A|B|C p) {
>> // do something
>> }
>>
>> def m(D|E p) {
>> // do something
>> }
>> }
>>
>> Groovy will translate the above code into the following code, which
>> is
>> also the same way how multi-catch is handled.
>>
>> class UnionTypeSample {
>> public UnionTypeSample(A p) {
>> // do something
>> }
>>
>> public UnionTypeSample(B p) {
>> // do something
>> }
>>
>> public UnionTypeSample(C p) {
>> // do something
>> }
>>
>> def m(D p) {
>> // do something
>> }
>>
>> def m(E p) {
>> // do something
>> }
>> }
>>
>> Any thoughts?
>> ----------------------------------
>> [+1] I like it
>> [ 0] Not bad
>> [-1] I do not like it
>> ----------------------------------
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> --
>> View this message in context: http://groovy.329449.n5.nabble
>> .com/VOTE-About-the-Union-Type-for-method-constructor-
>> declaration-tp5742265.html
>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>
>
>
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Paul King <pa...@asert.com.au>.
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?
Cheers, Paul.
On Sun, Jul 23, 2017 at 8:28 AM, Daniel Sun <re...@hotmail.com> wrote:
> Hi all,
>
> I've been thinking about Union Type for method/constructor
> declaration. It is similar to multi-catch in try-catch statement, e.g.
>
> class UnionTypeSample {
> public UnionTypeSample(A|B|C p) {
> // do something
> }
>
> def m(D|E p) {
> // do something
> }
> }
>
> Groovy will translate the above code into the following code, which
> is
> also the same way how multi-catch is handled.
>
> class UnionTypeSample {
> public UnionTypeSample(A p) {
> // do something
> }
>
> public UnionTypeSample(B p) {
> // do something
> }
>
> public UnionTypeSample(C p) {
> // do something
> }
>
> def m(D p) {
> // do something
> }
>
> def m(E p) {
> // do something
> }
> }
>
> Any thoughts?
> ----------------------------------
> [+1] I like it
> [ 0] Not bad
> [-1] I do not like it
> ----------------------------------
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/VOTE-About-the-Union-Type-for-method-constructor-declaration-
> tp5742265.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Andres Almiray <aa...@gmail.com>.
+1 to Paul's approach
https://www.youtube.com/watch?v=GMNvOtQFro0
-------------------------------------------
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Mon, Jul 24, 2017 at 8:32 PM, Paul King <pa...@asert.com.au> wrote:
> It's the kind of new feature (potentially wide impacting) that we have
> created Groovy Enhancement Proposals for in the past. Most recently we have
> just used well-fleshed out Jira issues with a GEP label.
>
> I'm +1 for exploring the idea further but -1 for trying to implement a
> small piece of the feature without at least fleshing out the bigger picture.
>
> Cheers, Paul.
>
>
> On 24 Jul. 2017 12:14 am, "Guillaume Laforge" <gl...@gmail.com> wrote:
>
>> Many people do also like that feature :-)
>> And it's good to have that conversation and discussion!
>>
>> Guillaume
>>
>> On Mon, Jul 24, 2017 at 2:06 AM, Daniel Sun <re...@hotmail.com>
>> wrote:
>>
>>> 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: http://groovy.329449.n5.nabble
>>> .com/VOTE-About-the-Union-Type-for-method-constructor-declar
>>> ation-tp5742265p5742283.html
>>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Paul King <pa...@asert.com.au>.
It's the kind of new feature (potentially wide impacting) that we have
created Groovy Enhancement Proposals for in the past. Most recently we have
just used well-fleshed out Jira issues with a GEP label.
I'm +1 for exploring the idea further but -1 for trying to implement a
small piece of the feature without at least fleshing out the bigger picture.
Cheers, Paul.
On 24 Jul. 2017 12:14 am, "Guillaume Laforge" <gl...@gmail.com> wrote:
> Many people do also like that feature :-)
> And it's good to have that conversation and discussion!
>
> Guillaume
>
> On Mon, Jul 24, 2017 at 2:06 AM, Daniel Sun <re...@hotmail.com>
> wrote:
>
>> 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: http://groovy.329449.n5.nabble
>> .com/VOTE-About-the-Union-Type-for-method-constructor-
>> declaration-tp5742265p5742283.html
>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Guillaume Laforge <gl...@gmail.com>.
Many people do also like that feature :-)
And it's good to have that conversation and discussion!
Guillaume
On Mon, Jul 24, 2017 at 2:06 AM, Daniel Sun <re...@hotmail.com> wrote:
> 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: http://groovy.329449.n5.
> nabble.com/VOTE-About-the-Union-Type-for-method-constructor-declaration-
> tp5742265p5742283.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Daniel Sun <re...@hotmail.com>.
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: http://groovy.329449.n5.nabble.com/VOTE-About-the-Union-Type-for-method-constructor-declaration-tp5742265p5742283.html
Sent from the Groovy Users mailing list archive at Nabble.com.
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Daniel Sun <re...@hotmail.com>.
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: http://groovy.329449.n5.nabble.com/VOTE-About-the-Union-Type-for-method-constructor-declaration-tp5742265p5742274.html
Sent from the Groovy Users mailing list archive at Nabble.com.
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Jochen Theodorou <bl...@gmx.org>.
On 23.07.2017 00:28, Daniel Sun wrote:
> Hi all,
>
> I've been thinking about Union Type for method/constructor
> declaration. It is similar to multi-catch in try-catch statement, e.g.
>
> class UnionTypeSample {
> public UnionTypeSample(A|B|C p) {
> // do something
> }
>
> def m(D|E p) {
> // do something
> }
> }
>
> Groovy will translate the above code into the following code, which is
> also the same way how multi-catch is handled.
>
> class UnionTypeSample {
> public UnionTypeSample(A p) {
> // do something
> }
>
> public UnionTypeSample(B p) {
> // do something
> }
>
> public UnionTypeSample(C p) {
> // do something
> }
>
> def m(D p) {
> // do something
> }
>
> def m(E p) {
> // do something
> }
> }
>
> Any thoughts?
writing while thinking about it... how about static compilation and
related: AST modeling? I assume you intend to do this transformation at
a pretty early stage, copying the AST nodes into other methods. But I
really would not call this union types, maybe union overloads or such.
Union types would go much much further.
For example in
def y
if (x) {
y = 1
} else {
y = "1"
}
y should then have the type (Integer|String) in static compilation,
while right now this is going to be a union of all the common classes of
Integer and String. Which means an intersection, just not limited to a
single type. And I think at this point simple AST copying will no longer
do the job. This would mandate a new AST element. And I think for a
clean solution we should then actually rewrite ClassNode. Syntax wise I
I think we can solve a problem like this:
def A,B
def y = {A|B param -> A|B}
I do not see a blocker here right now. But of course the alternative is
to declare the type and bypass the representation problem in a ClassNode
as well as possible syntax problems:
class union MyUnionTypeABC = A|B|C
class union MyUnionTypeDE = D|E
class UnionTypeSample {
public UnionTypeSample(MyUnionTypeABC p) {
// do something
}
def m(MyUnionTypeDE p) {
// do something
}
}
of course we still need a syntax for the definition after all... I guess
nothing is really easy in the end.
And if we are never going to do full union types, is it then worth
having the overload union only?
I think code coverage tools will have a problem with this, but maybe
they would regardless what implementation we would choose.
bye Jochen
Re: [VOTE]About the Union Type for method/constructor declaration
Posted by Ahm Avoby <al...@gmail.com>.
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 <re...@hotmail.com> schrieb am So., 23. Juli 2017, 00:28:
> Hi all,
>
> I've been thinking about Union Type for method/constructor
> declaration. It is similar to multi-catch in try-catch statement, e.g.
>
> class UnionTypeSample {
> public UnionTypeSample(A|B|C p) {
> // do something
> }
>
> def m(D|E p) {
> // do something
> }
> }
>
> Groovy will translate the above code into the following code, which
> is
> also the same way how multi-catch is handled.
>
> class UnionTypeSample {
> public UnionTypeSample(A p) {
> // do something
> }
>
> public UnionTypeSample(B p) {
> // do something
> }
>
> public UnionTypeSample(C p) {
> // do something
> }
>
> def m(D p) {
> // do something
> }
>
> def m(E p) {
> // do something
> }
> }
>
> Any thoughts?
> ----------------------------------
> [+1] I like it
> [ 0] Not bad
> [-1] I do not like it
> ----------------------------------
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/VOTE-About-the-Union-Type-for-method-constructor-declaration-tp5742265.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>