Mailing-List: contact users-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.apache.org
Subject: Re: [VOTE]About the Union Type for method/constructor declaration
To: users@groovy.apache.org, Paul King <paulk@asert.com.au>
References: <1500762487438-5742265.post@n5.nabble.com>
 <CAMbkE7S7fYo+MELrHXhTUNfqHFVNQCvV3=Wrr90ZQ2fJ_0N6OQ@mail.gmail.com>
From: MG <mgbiz@arscreat.com>
Message-ID: <1a853d3c-73c5-0a42-a480-645010981c87@arscreat.com>
Date: Sun, 23 Jul 2017 02:13:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAMbkE7S7fYo+MELrHXhTUNfqHFVNQCvV3=Wrr90ZQ2fJ_0N6OQ@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------1205975A4F9663ED1E0CC3A8"
Content-Language: en-US
archived-at: Sun, 23 Jul 2017 00:14:16 -0000

This is a multi-part message in MIME format.
--------------1205975A4F9663ED1E0CC3A8
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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 
> <mailto:realbluesun@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.
>
>


--------------1205975A4F9663ED1E0CC3A8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    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.<br>
    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<br>
    void
doGenericStuff(DeviceManager|VerySpecializedClassWithLongName|TautologicalFluxCompensatorMatrixElement|KungFooMaster
    x) { ... }<br>
    On the other hand, IDE refactoring support could allow for automatic
    extraction of a shared functionality interface between the given
    classes here...<br>
    <br>
    I would also have thought of the exact same syntax - can you explain
    why you think it would break future extensions, Paul ?<br>
    mg<br>
    <br>
    <div class="moz-cite-prefix">On 23.07.2017 01:50, Paul King wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMbkE7S7fYo+MELrHXhTUNfqHFVNQCvV3=Wrr90ZQ2fJ_0N6OQ@mail.gmail.com">
      <div dir="ltr">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?
        <div><br>
        </div>
        <div>Cheers, Paul.</div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Sun, Jul 23, 2017 at 8:28 AM, Daniel
          Sun <span dir="ltr">&lt;<a
              href="mailto:realbluesun@hotmail.com" target="_blank"
              moz-do-not-send="true">realbluesun@hotmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
            <br>
                   I've been thinking about Union Type for
            method/constructor<br>
            declaration. It is similar to multi-catch in try-catch
            statement, e.g.<br>
            <br>
            class UnionTypeSample {<br>
              public UnionTypeSample(A|B|C p) {<br>
                 // do something<br>
              }<br>
            <br>
              def m(D|E p) {<br>
                // do something<br>
              }<br>
            }<br>
            <br>
                  Groovy will translate the above code into the
            following code, which is<br>
            also the same way how multi-catch is handled.<br>
            <br>
            class UnionTypeSample {<br>
              public UnionTypeSample(A p) {<br>
                 // do something<br>
              }<br>
            <br>
              public UnionTypeSample(B p) {<br>
                 // do something<br>
              }<br>
            <br>
              public UnionTypeSample(C p) {<br>
                 // do something<br>
              }<br>
            <br>
              def m(D p) {<br>
                // do something<br>
              }<br>
            <br>
              def m(E p) {<br>
                // do something<br>
              }<br>
            }<br>
            <br>
                 Any thoughts?<br>
            ------------------------------<wbr>----<br>
              [+1] I like it<br>
              [  0] Not bad<br>
              [-1] I do not like it<br>
            ------------------------------<wbr>----<br>
            <br>
            Cheers,<br>
            Daniel.Sun<br>
            <br>
            <br>
            <br>
            --<br>
            View this message in context: <a
href="http://groovy.329449.n5.nabble.com/VOTE-About-the-Union-Type-for-method-constructor-declaration-tp5742265.html"
              rel="noreferrer" target="_blank" moz-do-not-send="true">http://groovy.329449.n5.<wbr>nabble.com/VOTE-About-the-<wbr>Union-Type-for-method-<wbr>constructor-declaration-<wbr>tp5742265.html</a><br>
            Sent from the Groovy Users mailing list archive at
            Nabble.com.<br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------1205975A4F9663ED1E0CC3A8--