Re: [VOTE]About the Union Type for method/constructor declaration

2017-07-24 Thread Andres Almiray 
+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  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"  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 
>> 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  / Google+
>> 
>>
>

Re: [VOTE]About the Union Type for method/constructor declaration

2017-07-24 Thread Paul King 
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" <glafo...@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 <realblue...@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

2017-07-24 Thread Guillaume Laforge 
On Mon, Jul 24, 2017 at 10:04 AM, Jochen Theodorou 
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  / Google+

Re: [VOTE]About the Union Type for method/constructor declaration

2017-07-24 Thread Jochen Theodorou 



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

2017-07-24 Thread Guillaume Laforge 
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 <realblue...@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

2017-07-23 Thread Daniel Sun 
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

2017-07-23 Thread Ahm Avoby 
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 <realblue...@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.
>

Re: [VOTE]About the Union Type for method/constructor declaration

2017-07-23 Thread Paolo Di Tommaso 
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 <realblue...@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

2017-07-23 Thread Daniel Sun 
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

2017-07-23 Thread Dierk König 
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 <realblue...@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

2017-07-22 Thread Paul King 
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 <realblue...@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.
>

[VOTE]About the Union Type for method/constructor declaration

2017-07-22 Thread Daniel Sun 
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.