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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

paulk_asert
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 <[hidden email]> 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.

MG
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

MG
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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jochen Theodorou
In reply to this post by Daniel Sun
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Dierk König
In reply to this post by MG
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 <[hidden email]>:

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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Sun
In reply to this post by Jochen Theodorou
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Paolo Di Tommaso
In reply to this post by paulk_asert
I agree with Paul. 

-1 


p

On Sun, Jul 23, 2017 at 1:50 AM, Paul King <[hidden email]> 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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Guillaume Laforge
Administrator
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:
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 <[hidden email]> wrote:
I agree with Paul. 

-1 


p

On Sun, Jul 23, 2017 at 1:50 AM, Paul King <[hidden email]> 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 <[hidden email]> 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.





--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Ahm Avoby
In reply to this post by Daniel Sun
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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Sun
In reply to this post by 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
12
Loading...