simplification MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7823106168118235853=="
--===============7823106168118235853== Content-Type: multipart/alternative; boundary="----4SVSQE8L3ECYN7Z8RACUF07S828YYG" ------4SVSQE8L3ECYN7Z8RACUF07S828YYG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I haven't been completely following this discussion as it's a bit over my head, but if two different types define a method of the same name, it seems to me that there'd be no ambiguity. Java allows function overloading; wouldn't this sort of be similar? From: Patrick Walton Sent: =E2=80=8E10/=E2=80=8E20/=E2=80=8E2013 2:01 PM To: G=C3=A1bor Lehel; Marijn Haverbeke Cc: [email protected] Subject: Re: [rust-dev] Unified function/method call syntax and further simplification What would happen if two types defined a method called, say, "foo", and the= importing module glob imported them both? Patrick "G=C3=A1bor Lehel" <[email protected]> wrote: >On Sun, Oct 20, 2013 at 7:31 PM, G=C3=A1bor Lehel <[email protected]> >wrote: > >> So I very much agree with Patrick. Some aspects of this proposal are >>> attractive, but it breaks some essential properties of the way >methods >>> currently work (and probably can't be adjusted to work around that >>> without losing most of it attraction). >>> >> >> The main cost would be having to import methods explicitly (or using >a >> glob), as Patrick notes. >> > >Now I'm wondering, though: going with my proposal, if the module >structure >were just a little bit more fine-grained, I think you could achieve >basically the same effect as the current system, if you wanted to. If >the >convention were to use a module to enclose a type together with its >methods >(which is already the case in many places), and you did a glob import >of >that module, you would get what you have now: the type and its methods >would all come into scope. Except you could still import selectively, >if >you wanted to, or do things any other way, if you wanted to, and all of >the >"warts" I mentioned would still disappear. In a different crate, you >could >similarly create a module of "extension methods", which could be >imported >together or selectively, if you wanted to. > >I don't want to push this too hard if it's past the point of being >productive, but I'm now even more convinced that this would be a >beneficial >change. Types should be types, grouping and scoping should be done with >modules (Rust's modules are very capable), and traits should be used >for >type-based abstraction. I think it would work great. > >--=20 >Your ship was destroyed in a monadic eruption. --=20 Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------4SVSQE8L3ECYN7Z8RACUF07S828YYG Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <HTML><HEAD> <META content=3D"text/html; charset=3Dutf-8" http-equiv=3DContent-Type></HE= AD> <BODY> <DIV> <DIV style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">I haven't b= een completely following this discussion as it's a bit over my head, but if= two different types define a method of the same name, it seems to me that = there'd be no ambiguity. Java allows function overloading; wouldn't this so= rt of be similar?</DIV></DIV> <DIV dir=3Dltr> <HR> <SPAN style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH= T: bold">From: </SPAN><SPAN style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,= sans-serif"><A href=3D"mailto:[email protected]";>Patrick Walton</A></SPAN= ><BR><SPAN style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-= WEIGHT: bold">Sent: </SPAN><SPAN style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Cal= ibri,sans-serif">=E2=80=8E10/=E2=80=8E20/=E2=80=8E2013 2:01 PM</SPAN><BR><S= PAN style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT:= bold">To: </SPAN><SPAN style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans= -serif"><A href=3D"mailto:[email protected]";>G=C3=A1bor Lehel</A>; <A hre= f=3D"mailto:[email protected]";>Marijn Haverbeke</A></SPAN><BR><SPAN style= =3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">Cc= : </SPAN><SPAN style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><= A href=3D"mailto:[email protected]";>[email protected]</A></SPAN><BR><= SPAN style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT= : bold">Subject: </SPAN><SPAN style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibr= i,sans-serif">Re: [rust-dev] Unified function/method call syntax and furthe= r simplification</SPAN><BR><BR></DIV></BODY></HTML><html><head></head><body= >What would happen if two types defined a method called, say, "foo&quo= t;, and the importing module glob imported them both?<br> <br> Patrick<br><br><div class=3D"gmail_quote">"G=C3=A1bor Lehel" <= [email protected]> wrote:<blockquote class=3D"gmail_quote" style=3D"ma= rgin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding= -left: 1ex;"> <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S= un, Oct 20, 2013 at 7:31 PM, G=C3=A1bor Lehel <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]"; target=3D"_blank">[email protected]</a>&g= t;</span> wrote:<br /> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla= ss=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im"><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= lid rgb(204,204,204);padding-left:1ex"> So I very much agree with Patrick. Some aspects of this proposal are<br /> attractive, but it breaks some essential properties of the way methods<br /= > currently work (and probably can't be adjusted to work around that<br /= > without losing most of it attraction).<br clear=3D"all" /></blockquote><div= ><br /></div></div><div>The main cost would be having to import methods exp= licitly (or using a glob), as Patrick notes.<br /></div></div></div></div><= /blockquote> <div><br /></div><div>Now I'm wondering, though: going with my proposal= , if the module structure were just a little bit more fine-grained, I think= you could achieve basically the same effect as the current system, if you = wanted to. If the convention were to use a module to enclose a type togethe= r with its methods (which is already the case in many places), and you did = a glob import of that module, you would get what you have now: the type and= its methods would all come into scope. Except you could still import selec= tively, if you wanted to, or do things any other way, if you wanted to, and= all of the "warts" I mentioned would still disappear. In a diffe= rent crate, you could similarly create a module of "extension methods&= quot;, which could be imported together or selectively, if you wanted to.<b= r /> <br /></div><div>I don't want to push this too hard if it's past th= e point of being productive, but I'm now even more convinced that this = would be a beneficial change. Types should be types, grouping and scoping s= hould be done with modules (Rust's modules are very capable), and trait= s should be used for type-based abstraction. I think it would work great.<b= r /> <br /></div></div>-- <br />Your ship was destroyed in a monadic eruption. </div></div> </blockquote></div><br> -- <br> Sent from my Android phone with K-9 Mail. Please excuse my brevity.</body><= /html> ------4SVSQE8L3ECYN7Z8RACUF07S828YYG-- --===============7823106168118235853== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev --===============7823106168118235853==-- _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
