From peter.kitt.reilly at gmail.com Sat Aug 6 03:41:05 2011 From: peter.kitt.reilly at gmail.com (Peter Reilly) Date: Sat, 6 Aug 2011 11:41:05 +0100 Subject: Multiline string literals Message-ID: Now that jdk7 is released and there will shortly be a process for asking for new small features in jdk8, I would like to ask that support for multiline string literals be considered. This is a long standing request and a specific proposal is contained in: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000087.html An example of the current mess is in: http://blog.voidsearch.com/bigdata/apache-avro-in-practice/ String schemaDescription = " { \n" + " \"name\": \"FacebookUser\", \n" + " \"type\": \"record\",\n" + " \"fields\": [\n" + " {\"name\": \"name\", \"type\": \"string\"},\n" + " {\"name\": \"num_likes\", \"type\": \"int\"},\n" + " {\"name\": \"num_photos\", \"type\": \"int\"},\n" + " {\"name\": \"num_groups\", \"type\": \"int\"} ]\n" + "}"; it would be *much* nicer to say: String schemaDescription = """{ "name": "FacebookUser", "type": "record", "fields": [ {"name": "name", "type": "string"}, {"name": "num_likes", "type": "int\"}, {"name": "num_photos", "type": "int"}, {"name": "num_groups", "type": "int"} ] }"""; Peter From per at bothner.com Sat Aug 6 08:12:22 2011 From: per at bothner.com (Per Bothner) Date: Sat, 06 Aug 2011 08:12:22 -0700 Subject: Multiline string literals In-Reply-To: References: Message-ID: <4E3D59D6.3040309@bothner.com> On 08/06/2011 03:41 AM, Peter Reilly wrote: > Now that jdk7 is released and there will shortly be a process for > asking for new small features in jdk8, I would like to ask that > support for multiline string literals be considered. > > This is a long standing request and a specific proposal is contained in: > > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000087.html I think it would be a mistake for multiline string literals to have the ending delimiter be the same as the starting delimiter. It seems lie it would make things more difficult for IDEs. Using """ also seems prone to syntax errors with possibly-confusing error messages. And it makes it harder to scan the text (visually or with tools) for matching delimiters. I also think this is a questionable idea: String platformDepended="""q """; is 'q\n' if compiled on Unix and 'q\n\r' if compiled on Windows. This make the meaning of a program depend on which platform it is compiled on. Probably not something we want. You could change it to depend on the program it is *run* on, by defining it in terms of line.separator - that would make more sense. -- --Per Bothner per at bothner.com http://per.bothner.com/ From isidore at setgame.com Sat Aug 6 09:03:39 2011 From: isidore at setgame.com (Llewellyn Falco) Date: Sat, 6 Aug 2011 09:03:39 -0700 Subject: Multiline string literals References: Message-ID: <8020A121-F91F-44E7-A686-1D66175AE323@setgame.com> > > Peter bring up an interesting point about line returns being dependent on platform. > > I believe there are 5 choices > 1) all multiline strings are _____ (either "\r\n" or "\n") > 2) it depends who compiled it > 3) it depends who runs it > 4) it must be stated > 5) combination of 1&4 ( it can be stated ) > > I just wanted to explore these options. > > 1) this is consistent, which I like, but also religious which I don't like. However it would also allow for things like ""hello"".replace( "\r\n", "\n") > > 2) this might be confusing when compiled on different platforms, which is weird. But I also believe it would less likely to have multi-platform compiles.. This would be intuitive for new programmers. I believe this favors strings that are not spilt afterwards > > 3) these bugs would not only be confusing, they would be hard to reproduce. I believe this favors things that are manipulated after. > > 4) it could be like blah blah blah or > @LineBreaks( "\r\n") > Public void foo(){ > string s =""blah blah blah""; > } > > 5) I think this is self explanatory > > Llewellyn. > > Ps. Java syntax is hard on an iPad :-( > > > Sent from my iPad > > On Aug 6, 2011, at 8:12 AM, Per Bothner wrote: > >> On 08/06/2011 03:41 AM, Peter Reilly wrote: >>> Now that jdk7 is released and there will shortly be a process for >>> asking for new small features in jdk8, I would like to ask that >>> support for multiline string literals be considered. >>> >>> This is a long standing request and a specific proposal is contained in: >>> >>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000087.html >> >> I think it would be a mistake for multiline string literals to have >> the ending delimiter be the same as the starting delimiter. It seems >> lie it would make things more difficult for IDEs. Using """ also seems >> prone to syntax errors with possibly-confusing error messages. And it makes >> it harder to scan the text (visually or with tools) for matching delimiters. >> >> I also think this is a questionable idea: >> >> String platformDepended="""q >> """; >> is 'q\n' if compiled on Unix and 'q\n\r' if compiled on Windows. >> >> This make the meaning of a program depend on which platform >> it is compiled on. Probably not something we want. You could >> change it to depend on the program it is *run* on, by defining it >> in terms of line.separator - that would make more sense. >> -- >> --Per Bothner >> per at bothner.com http://per.bothner.com/ >> From serge.boulay at gmail.com Sat Aug 6 11:31:40 2011 From: serge.boulay at gmail.com (Serge Boulay) Date: Sat, 6 Aug 2011 14:31:40 -0400 Subject: Multiline string literals In-Reply-To: <8020A121-F91F-44E7-A686-1D66175AE323@setgame.com> References: <8020A121-F91F-44E7-A686-1D66175AE323@setgame.com> Message-ID: I'm curious how Groovy and Scala do this because they both have multiline string literals. On Sat, Aug 6, 2011 at 12:03 PM, Llewellyn Falco wrote: > > > > > > Peter bring up an interesting point about line returns being dependent on > platform. > > > > I believe there are 5 choices > > 1) all multiline strings are _____ (either "\r\n" or "\n") > > 2) it depends who compiled it > > 3) it depends who runs it > > 4) it must be stated > > 5) combination of 1&4 ( it can be stated ) > > > > I just wanted to explore these options. > > > > 1) this is consistent, which I like, but also religious which I don't > like. However it would also allow for things like ""hello"".replace( "\r\n", > "\n") > > > > 2) this might be confusing when compiled on different platforms, which is > weird. But I also believe it would less likely to have multi-platform > compiles.. This would be intuitive for new programmers. I believe this > favors strings that are not spilt afterwards > > > > 3) these bugs would not only be confusing, they would be hard to > reproduce. I believe this favors things that are manipulated after. > > > > 4) it could be like blah blah blah > or > > @LineBreaks( "\r\n") > > Public void foo(){ > > string s =""blah blah blah""; > > } > > > > 5) I think this is self explanatory > > > > Llewellyn. > > > > Ps. Java syntax is hard on an iPad :-( > > > > > > Sent from my iPad > > > > On Aug 6, 2011, at 8:12 AM, Per Bothner wrote: > > > >> On 08/06/2011 03:41 AM, Peter Reilly wrote: > >>> Now that jdk7 is released and there will shortly be a process for > >>> asking for new small features in jdk8, I would like to ask that > >>> support for multiline string literals be considered. > >>> > >>> This is a long standing request and a specific proposal is contained > in: > >>> > >>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000087.html > >> > >> I think it would be a mistake for multiline string literals to have > >> the ending delimiter be the same as the starting delimiter. It seems > >> lie it would make things more difficult for IDEs. Using """ also seems > >> prone to syntax errors with possibly-confusing error messages. And it > makes > >> it harder to scan the text (visually or with tools) for matching > delimiters. > >> > >> I also think this is a questionable idea: > >> > >> String platformDepended="""q > >> """; > >> is 'q\n' if compiled on Unix and 'q\n\r' if compiled on Windows. > >> > >> This make the meaning of a program depend on which platform > >> it is compiled on. Probably not something we want. You could > >> change it to depend on the program it is *run* on, by defining it > >> in terms of line.separator - that would make more sense. > >> -- > >> --Per Bothner > >> per at bothner.com http://per.bothner.com/ > >> > > From peter.kitt.reilly at gmail.com Sat Aug 6 12:48:51 2011 From: peter.kitt.reilly at gmail.com (Peter Reilly) Date: Sat, 6 Aug 2011 20:48:51 +0100 Subject: Multiline string literals In-Reply-To: References: <8020A121-F91F-44E7-A686-1D66175AE323@setgame.com> Message-ID: Along with, ruby, python, perl, bash. The only problem is handling of new-lines. The proposal http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000087.html suggests using a trailing U (for \n) or W (for \r\n) to identify which line ending to use. so String tablecreate = """ CREATE TABLE device ( addr INTEGER UNSIGNED NOT NULL, name VARCHAR(255) NOT NULL, descr VARCHAR(255), snmpver TINYINT, snmpcomm VARCHAR(255), location VARCHAR(255), PRIMARY KEY(addr) ) ENGINE=INNODB; """U; for \n endings. Peter On Sat, Aug 6, 2011 at 7:31 PM, Serge Boulay wrote: > I'm curious how Groovy and Scala do this because they both have multiline > string literals. > > On Sat, Aug 6, 2011 at 12:03 PM, Llewellyn Falco wrote: > >> >> > >> >> > Peter bring up an interesting point about line returns being dependent on >> platform. >> > >> > I believe there are 5 choices >> > 1) all multiline strings are _____ (either "\r\n" or "\n") >> > 2) it depends who compiled it >> > 3) it depends who runs it >> > 4) it must be stated >> > 5) combination of 1&4 ( it can be stated ) >> > >> > I just wanted to explore these options. >> > >> > 1) this is consistent, which I like, but also religious which I don't >> like. However it would also allow for things like ""hello"".replace( "\r\n", >> "\n") >> > >> > 2) this might be confusing when compiled on different platforms, which is >> weird. But I also believe it would less likely to have multi-platform >> compiles.. This would be intuitive for new programmers. I believe this >> favors strings that are not spilt afterwards >> > >> > 3) these bugs would not only be confusing, they would be hard to >> reproduce. I believe this favors things that are manipulated after. >> > >> > 4) it could be like blah blah blah >> or >> > @LineBreaks( "\r\n") >> > Public void foo(){ >> > string s =""blah blah blah""; >> > } >> > >> > 5) I think this is self explanatory >> > >> > Llewellyn. >> > >> > Ps. Java syntax is hard on an iPad :-( >> > >> > >> > Sent from my iPad >> > >> > On Aug 6, 2011, at 8:12 AM, Per Bothner wrote: >> > >> >> On 08/06/2011 03:41 AM, Peter Reilly wrote: >> >>> Now that jdk7 is released and there will shortly be a process for >> >>> asking for new small features in jdk8, I would like to ask that >> >>> support for multiline string literals be considered. >> >>> >> >>> This is a long standing request and a specific proposal is contained >> in: >> >>> >> >>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000087.html >> >> >> >> I think it would be a mistake for multiline string literals to have >> >> the ending delimiter be the same as the starting delimiter. ?It seems >> >> lie it would make things more difficult for IDEs. ?Using """ also seems >> >> prone to syntax errors with possibly-confusing error messages. ?And it >> makes >> >> it harder to scan the text (visually or with tools) for matching >> delimiters. >> >> >> >> I also think this is a questionable idea: >> >> >> >> String platformDepended="""q >> >> """; >> >> is 'q\n' if compiled on Unix and 'q\n\r' if compiled on Windows. >> >> >> >> This make the meaning of a program depend on which platform >> >> it is compiled on. ?Probably not something we want. ?You could >> >> change it to depend on the program it is *run* on, by defining it >> >> in terms of line.separator - that would make more sense. >> >> -- >> >> ? --Per Bothner >> >> per at bothner.com ? http://per.bothner.com/ >> >> >> >> > > From ruslan at shevchenko.kiev.ua Sat Aug 6 13:30:14 2011 From: ruslan at shevchenko.kiev.ua (Ruslan Shevchenko) Date: Sat, 6 Aug 2011 23:30:14 +0300 Subject: Multiline string literals In-Reply-To: <4E3D59D6.3040309@bothner.com> References: <4E3D59D6.3040309@bothner.com> Message-ID: 1. Last submission: 1.4 for multiine string literals is http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000747.html which in many aspects differ from first version. Also, I maintain 'post-morten' final version: https://docs.google.com/Doc?docid=0AX56ZsgNVurJZGhodmdncjhfMjFncjVzNGZoZw which can be used as starting point, if Oracle decide to receive proposals about language direction from external world with reopening or creation of some analog of project coin. [my estimation for probability of such case is not very hight.] 2. In general, this proposal describe multiline strings as they implemented in scala and groovy now. One problem with this: """ are IDE-unfriendly: complexity of implementing mulitline string support for groovy in netbeans shows this. So, now I think that """" symbols in proposal is better change to pair of "( )" (and '( )' for row string literals), simular to brackets for multiline string literals in C++0x http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm Regards ! On Sat, Aug 6, 2011 at 6:12 PM, Per Bothner wrote: > On 08/06/2011 03:41 AM, Peter Reilly wrote: >> Now that jdk7 is released and there will shortly be a process for >> asking for new small features in jdk8, I would like to ask that >> support for multiline string literals be considered. >> >> This is a long standing request and a specific proposal is contained in: >> >> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000087.html > > I think it would be a mistake for multiline string literals to have > the ending delimiter be the same as the starting delimiter. ?It seems > lie it would make things more difficult for IDEs. ?Using """ also seems > prone to syntax errors with possibly-confusing error messages. ?And it makes > it harder to scan the text (visually or with tools) for matching delimiters. > > I also think this is a questionable idea: > > String platformDepended="""q > """; > is 'q\n' if compiled on Unix and 'q\n\r' if compiled on Windows. > > This make the meaning of a program depend on which platform > it is compiled on. ?Probably not something we want. ?You could > change it to depend on the program it is *run* on, by defining it > in terms of line.separator - that would make more sense. > -- > ? ? ? ?--Per Bothner > per at bothner.com ? http://per.bothner.com/ > > From peter.kitt.reilly at gmail.com Sat Aug 6 15:16:40 2011 From: peter.kitt.reilly at gmail.com (Peter Reilly) Date: Sat, 6 Aug 2011 23:16:40 +0100 Subject: Multiline string literals In-Reply-To: References: <4E3D59D6.3040309@bothner.com> Message-ID: Thanks for the update! my google powers are pretty poor ;-) I do not agree that """ is IDE unfriendly, at least in the sense that is is supported by the three main java ides (for groovy), and in theory any editor that supports python. Back in 2006 (yicks, is it that long ago), I hacked the javac compiler to add support for """ multiline support, it was ridiculously easy - see http://peter-reilly.blogspot.com/2006/11/multiline-strings-in-java-part-2.html Peter On Sat, Aug 6, 2011 at 9:30 PM, Ruslan Shevchenko wrote: > 1. Last submission: 1.4 for multiine string literals is > ? ? http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000747.html > ?which in many aspects differ from first version. > > Also, I maintain 'post-morten' final version: > ? https://docs.google.com/Doc?docid=0AX56ZsgNVurJZGhodmdncjhfMjFncjVzNGZoZw > ?which can be used as starting point, if Oracle decide to receive > proposals about language direction from external world with reopening > or creation of some analog ?of project coin. ? ?[my estimation for > probability of such case is not very hight.] > > 2. ?In general, this proposal describe multiline strings as they > implemented in scala and groovy now. ?One problem with this: """ are > IDE-unfriendly: complexity of implementing mulitline string support > for groovy in netbeans shows this. > > So, now I think that ?"""" ?symbols in proposal is better change to > pair of ?"( ? ?)" ? (and '( ? ?)' ?for row string literals), ?simular > to brackets for multiline string literals in C++0x > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm > > Regards ! > > On Sat, Aug 6, 2011 at 6:12 PM, Per Bothner wrote: >> On 08/06/2011 03:41 AM, Peter Reilly wrote: >>> Now that jdk7 is released and there will shortly be a process for >>> asking for new small features in jdk8, I would like to ask that >>> support for multiline string literals be considered. >>> >>> This is a long standing request and a specific proposal is contained in: >>> >>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000087.html >> >> I think it would be a mistake for multiline string literals to have >> the ending delimiter be the same as the starting delimiter. ?It seems >> lie it would make things more difficult for IDEs. ?Using """ also seems >> prone to syntax errors with possibly-confusing error messages. ?And it makes >> it harder to scan the text (visually or with tools) for matching delimiters. >> >> I also think this is a questionable idea: >> >> String platformDepended="""q >> """; >> is 'q\n' if compiled on Unix and 'q\n\r' if compiled on Windows. >> >> This make the meaning of a program depend on which platform >> it is compiled on. ?Probably not something we want. ?You could >> change it to depend on the program it is *run* on, by defining it >> in terms of line.separator - that would make more sense. >> -- >> ? ? ? ?--Per Bothner >> per at bothner.com ? http://per.bothner.com/ >> >> > > From weijun.wang at oracle.com Sat Aug 6 20:26:45 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 07 Aug 2011 11:26:45 +0800 Subject: Multiline string literals In-Reply-To: References: <4E3D59D6.3040309@bothner.com> Message-ID: <4E3E05F5.40408@oracle.com> This is an interesting topic. 1. I don't like a platform-dependent \n vs \r\n decision. Either you must provide U or W at the end, or the default is always \n. The same program compiling to different classes on different platforms just seems bad. 2. I prefer never escape anything. If you do want to put """ inside a string, do not using the new format. 3. I care more about other kind of white spaces. The de-indentation trick in the proposal should work in most cases. How about TABs in the string? How about trailing spaces? Most IDEs will remove trailing spaces. Thanks Max On 08/07/2011 04:30 AM, Ruslan Shevchenko wrote: > 1. Last submission: 1.4 for multiine string literals is > http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000747.html > which in many aspects differ from first version. > > Also, I maintain 'post-morten' final version: > https://docs.google.com/Doc?docid=0AX56ZsgNVurJZGhodmdncjhfMjFncjVzNGZoZw > which can be used as starting point, if Oracle decide to receive > proposals about language direction from external world with reopening > or creation of some analog of project coin. [my estimation for > probability of such case is not very hight.] > > 2. In general, this proposal describe multiline strings as they > implemented in scala and groovy now. One problem with this: """ are > IDE-unfriendly: complexity of implementing mulitline string support > for groovy in netbeans shows this. > > So, now I think that """" symbols in proposal is better change to > pair of "( )" (and '( )' for row string literals), simular > to brackets for multiline string literals in C++0x > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm > > Regards ! > > On Sat, Aug 6, 2011 at 6:12 PM, Per Bothner wrote: >> On 08/06/2011 03:41 AM, Peter Reilly wrote: >>> Now that jdk7 is released and there will shortly be a process for >>> asking for new small features in jdk8, I would like to ask that >>> support for multiline string literals be considered. >>> >>> This is a long standing request and a specific proposal is contained in: >>> >>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000087.html >> >> I think it would be a mistake for multiline string literals to have >> the ending delimiter be the same as the starting delimiter. It seems >> lie it would make things more difficult for IDEs. Using """ also seems >> prone to syntax errors with possibly-confusing error messages. And it makes >> it harder to scan the text (visually or with tools) for matching delimiters. >> >> I also think this is a questionable idea: >> >> String platformDepended="""q >> """; >> is 'q\n' if compiled on Unix and 'q\n\r' if compiled on Windows. >> >> This make the meaning of a program depend on which platform >> it is compiled on. Probably not something we want. You could >> change it to depend on the program it is *run* on, by defining it >> in terms of line.separator - that would make more sense. >> -- >> --Per Bothner >> per at bothner.com http://per.bothner.com/ >> >> > From ruslan at shevchenko.kiev.ua Sat Aug 6 22:44:36 2011 From: ruslan at shevchenko.kiev.ua (Ruslan Shevchenko) Date: Sun, 7 Aug 2011 08:44:36 +0300 Subject: Multiline string literals In-Reply-To: References: <4E3D59D6.3040309@bothner.com> Message-ID: On Sun, Aug 7, 2011 at 1:16 AM, Peter Reilly wrote: > Thanks for the update! > my google powers are pretty poor ;-) > > I do not agree that """ is IDE unfriendly, at > least in the sense that is is supported by > the three main java ides (for groovy), and in theory any editor > that supports python. > It was the point from people from NetBeans team, after implementing groovy support. ...... here-s explanation from Per Bothner: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001220.html > Back in 2006 (yicks, is it that long ago), I hacked > the javac compiler to add support for """ multiline support, > it was ridiculously easy ?- see > http://peter-reilly.blogspot.com/2006/11/multiline-strings-in-java-part-2.html > Yes, this link was in references section of proposal ;) > Peter > > On Sat, Aug 6, 2011 at 9:30 PM, Ruslan Shevchenko > wrote: >> 1. Last submission: 1.4 for multiine string literals is >> ? ? http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000747.html >> ?which in many aspects differ from first version. >> >> Also, I maintain 'post-morten' final version: >> ? https://docs.google.com/Doc?docid=0AX56ZsgNVurJZGhodmdncjhfMjFncjVzNGZoZw >> ?which can be used as starting point, if Oracle decide to receive >> proposals about language direction from external world with reopening >> or creation of some analog ?of project coin. ? ?[my estimation for >> probability of such case is not very hight.] >> >> 2. ?In general, this proposal describe multiline strings as they >> implemented in scala and groovy now. ?One problem with this: """ are >> IDE-unfriendly: complexity of implementing mulitline string support >> for groovy in netbeans shows this. >> >> So, now I think that ?"""" ?symbols in proposal is better change to >> pair of ?"( ? ?)" ? (and '( ? ?)' ?for row string literals), ?simular >> to brackets for multiline string literals in C++0x >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm >> >> Regards ! >> >> On Sat, Aug 6, 2011 at 6:12 PM, Per Bothner wrote: >>> On 08/06/2011 03:41 AM, Peter Reilly wrote: >>>> Now that jdk7 is released and there will shortly be a process for >>>> asking for new small features in jdk8, I would like to ask that >>>> support for multiline string literals be considered. >>>> >>>> This is a long standing request and a specific proposal is contained in: >>>> >>>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000087.html >>> >>> I think it would be a mistake for multiline string literals to have >>> the ending delimiter be the same as the starting delimiter. ?It seems >>> lie it would make things more difficult for IDEs. ?Using """ also seems >>> prone to syntax errors with possibly-confusing error messages. ?And it makes >>> it harder to scan the text (visually or with tools) for matching delimiters. >>> >>> I also think this is a questionable idea: >>> >>> String platformDepended="""q >>> """; >>> is 'q\n' if compiled on Unix and 'q\n\r' if compiled on Windows. >>> >>> This make the meaning of a program depend on which platform >>> it is compiled on. ?Probably not something we want. ?You could >>> change it to depend on the program it is *run* on, by defining it >>> in terms of line.separator - that would make more sense. >>> -- >>> ? ? ? ?--Per Bothner >>> per at bothner.com ? http://per.bothner.com/ >>> >>> >> >> > > From per at bothner.com Sat Aug 6 23:44:41 2011 From: per at bothner.com (Per Bothner) Date: Sat, 06 Aug 2011 23:44:41 -0700 Subject: Multiline string literals In-Reply-To: References: <4E3D59D6.3040309@bothner.com> Message-ID: <4E3E3459.6080902@bothner.com> On 08/06/2011 01:30 PM, Ruslan Shevchenko wrote: > So, now I think that """" symbols in proposal is better change to > pair of "( )" (and '( )' for row string literals), I don't see how this can work: "(foo)" is already well-defined in Java. '(foo)' seems unambiguous. -- --Per Bothner per at bothner.com http://per.bothner.com/ From ruslan at shevchenko.kiev.ua Sun Aug 7 00:00:34 2011 From: ruslan at shevchenko.kiev.ua (Ruslan Shevchenko) Date: Sun, 7 Aug 2011 10:00:34 +0300 Subject: Multiline string literals In-Reply-To: <4E3E3459.6080902@bothner.com> References: <4E3D59D6.3040309@bothner.com> <4E3E3459.6080902@bothner.com> Message-ID: Yes, you are right. from brackets and double quotes, only <" combination is safe. On Sun, Aug 7, 2011 at 9:44 AM, Per Bothner wrote: > On 08/06/2011 01:30 PM, Ruslan Shevchenko wrote: >> >> So, now I think that ?"""" ?symbols in proposal is better change to >> pair of ?"( ? ?)" ? (and '( ? ?)' ?for row string literals), > > I don't see how this can work: > > ?"(foo)" > > is already well-defined in Java. > > ?'(foo)' > > seems unambiguous. > -- > ? ? ? ?--Per Bothner > per at bothner.com ? http://per.bothner.com/ > From forax at univ-mlv.fr Sun Aug 7 05:36:56 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 07 Aug 2011 14:36:56 +0200 Subject: Multiline string literals In-Reply-To: References: <4E3D59D6.3040309@bothner.com> <4E3E3459.6080902@bothner.com> Message-ID: <4E3E86E8.20001@univ-mlv.fr> An why not using " ? why do we need a different syntax for single line and multiple lines string literals ? R?mi On 08/07/2011 09:00 AM, Ruslan Shevchenko wrote: > Yes, you are right. from brackets and double quotes, only<" > combination is safe. > > > On Sun, Aug 7, 2011 at 9:44 AM, Per Bothner wrote: >> On 08/06/2011 01:30 PM, Ruslan Shevchenko wrote: >>> So, now I think that """" symbols in proposal is better change to >>> pair of "( )" (and '( )' for row string literals), >> I don't see how this can work: >> >> "(foo)" >> >> is already well-defined in Java. >> >> '(foo)' >> >> seems unambiguous. >> -- >> --Per Bothner >> per at bothner.com http://per.bothner.com/ >> From abies at adres.pl Sun Aug 7 06:54:54 2011 From: abies at adres.pl (Artur Biesiadowski) Date: Sun, 07 Aug 2011 14:54:54 +0100 Subject: Multiline string literals In-Reply-To: <4E3E86E8.20001@univ-mlv.fr> References: <4E3D59D6.3040309@bothner.com> <4E3E3459.6080902@bothner.com> <4E3E86E8.20001@univ-mlv.fr> Message-ID: <4E3E992E.2010601@adres.pl> Because it is not only about multiline literals, it is about avoiding escaping common expressions - in particular, "" delimited strings. This is why somebody was discussing 'single line multiline string literal' here ;) Regards, Artur Biesiadowski On 07/08/2011 13:36, R?mi Forax wrote: > An why not using " ? > why do we need a different syntax for single line and multiple lines > string literals ? > From maurizio.cimadamore at oracle.com Mon Aug 8 01:16:53 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 08 Aug 2011 09:16:53 +0100 Subject: Multiline string literals In-Reply-To: <4E3E992E.2010601@adres.pl> References: <4E3D59D6.3040309@bothner.com> <4E3E3459.6080902@bothner.com> <4E3E86E8.20001@univ-mlv.fr> <4E3E992E.2010601@adres.pl> Message-ID: <4E3F9B75.7010007@oracle.com> On 07/08/11 14:54, Artur Biesiadowski wrote: > Because it is not only about multiline literals, it is about avoiding > escaping common expressions - in particular, "" delimited strings. > > This is why somebody was discussing 'single line multiline string > literal' here ;) Hi, it seems to me that we are asking for a silver bullet that solves all our string-related problems; how much would we need escaping for delimited strings if we had explicit syntax support for XML, JSON (etc.) literals (possibly checked at compile-time against a schema?) - at the end of the day, a string is a string - there's nothing much the compiler can do about it; on the other hand, most of the examples of multiline strings I've seen in this discussion do have a 'structure' that can be checked. Maurizio > Regards, > Artur Biesiadowski > > On 07/08/2011 13:36, R?mi Forax wrote: >> An why not using " ? >> why do we need a different syntax for single line and multiple lines >> string literals ? >> > From fweimer at bfk.de Mon Aug 8 01:50:44 2011 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 08 Aug 2011 08:50:44 +0000 Subject: Multiline string literals In-Reply-To: <4E3E86E8.20001@univ-mlv.fr> (=?iso-8859-1?Q?=22R=E9mi?= Forax"'s message of "Sun, 07 Aug 2011 14:36:56 +0200") References: <4E3D59D6.3040309@bothner.com> <4E3E3459.6080902@bothner.com> <4E3E86E8.20001@univ-mlv.fr> Message-ID: <82liv4uw0r.fsf@mid.bfk.de> * R?mi Forax: > An why not using " ? > why do we need a different syntax for single line and multiple lines > string literals ? It's difficult to provide good error messages for unterminated multi-line strings. The quoting argument is not very persuasive to me; I prefer occasional consistent quoting (as in XHTML and JSON) to rarely required quoting magic (as in Markdown in YAML). If you need quoting in the latter scenario, it's often quite difficult to figure out how to do it. As another syntactic option, Lua uses [[string]], [=[string]=], [==[string]==] and so on for multi-line strings, which can encode any string without special quoting rules. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From scolebourne at joda.org Mon Aug 8 02:56:39 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 8 Aug 2011 10:56:39 +0100 Subject: Multiline string literals In-Reply-To: <4E3F9B75.7010007@oracle.com> References: <4E3D59D6.3040309@bothner.com> <4E3E3459.6080902@bothner.com> <4E3E86E8.20001@univ-mlv.fr> <4E3E992E.2010601@adres.pl> <4E3F9B75.7010007@oracle.com> Message-ID: For those wanting to understand Maurizio's suggestion more, see how Fantom handles this: http://fantom.org/doc/docLang/DSLs.html Stephen On 8 August 2011 09:16, Maurizio Cimadamore wrote: > On 07/08/11 14:54, Artur Biesiadowski wrote: >> Because it is not only about multiline literals, it is about avoiding >> escaping common expressions - in particular, "" delimited strings. >> >> This is why somebody was discussing 'single line multiline string >> literal' here ;) > Hi, > it seems to me that we are asking for a silver bullet that solves all > our string-related problems; how much would we need escaping for > delimited strings if we had explicit syntax support for XML, JSON (etc.) > literals (possibly checked at compile-time against a schema?) - at the > end of the day, a string is a string - there's nothing much the compiler > can do about it; on the other hand, most of the examples of multiline > strings I've seen in this discussion do have a 'structure' that can be > checked. > > Maurizio >> Regards, >> Artur Biesiadowski >> >> On 07/08/2011 13:36, R?mi Forax wrote: >>> An why not using " ? >>> why do we need a different syntax for single line and multiple lines >>> string literals ? >>> >> > > > From brucechapman at paradise.net.nz Mon Aug 8 03:04:02 2011 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Mon, 08 Aug 2011 22:04:02 +1200 Subject: Multiline string literals In-Reply-To: <4E3F9B75.7010007@oracle.com> References: <4E3D59D6.3040309@bothner.com> <4E3E3459.6080902@bothner.com> <4E3E86E8.20001@univ-mlv.fr> <4E3E992E.2010601@adres.pl> <4E3F9B75.7010007@oracle.com> Message-ID: <4E3FB492.8050603@paradise.net.nz> On 8/08/2011 8:16 p.m., Maurizio Cimadamore wrote: > On 07/08/11 14:54, Artur Biesiadowski wrote: >> Because it is not only about multiline literals, it is about avoiding >> escaping common expressions - in particular, "" delimited strings. >> >> This is why somebody was discussing 'single line multiline string >> literal' here ;) > Hi, > it seems to me that we are asking for a silver bullet that solves all > our string-related problems; how much would we need escaping for > delimited strings if we had explicit syntax support for XML, JSON (etc.) > literals (possibly checked at compile-time against a schema?) Well, Java is a general purpose programming language, so general language features are (highly) favoured over application specific language features. Following that means it is better to have one string syntax that supports multiline strings (irrespective of whether or not that is the same as the existing syntax), tham to have separate syntax for XML, JSON, my_favourite_syntax or your_favourite_syntax. This applies at least until the general purpose syntax creates a high level of pain for a very common application - at which point a better syntax can be investigated. > - at the end of the day, a string is a string - there's nothing much the compiler > can do about it; Annotation processors (or some future similar compiler feature) can (could) parse the general purpose string against an application specific syntax and syntax specific errors could be generated at compile time. I've done it for XML. > on the other hand, most of the examples of multiline > strings I've seen in this discussion do have a 'structure' that can be > checked. > Yes, so hand in hand with a general purpose multiline string literal, it would be good to investigate ways of having pluggable syntax checkers for these. I don't believe this would require any new language feature. I can provide a strawman if there is interest. Bruce > Maurizio >> Regards, >> Artur Biesiadowski >> >> On 07/08/2011 13:36, R?mi Forax wrote: >>> An why not using " ? >>> why do we need a different syntax for single line and multiple lines >>> string literals ? >>> > From Kai.Kunstmann at combase.de Mon Aug 8 03:17:02 2011 From: Kai.Kunstmann at combase.de (Kai Kunstmann) Date: Mon, 8 Aug 2011 12:17:02 +0200 Subject: Multiline string literals In-Reply-To: <4E3F9B75.7010007@oracle.com> References: <4E3D59D6.3040309@bothner.com> <4E3E3459.6080902@bothner.com> <4E3E86E8.20001@univ-mlv.fr> <4E3E992E.2010601@adres.pl> <4E3F9B75.7010007@oracle.com> Message-ID: <1312798622.1722.144.camel@kak-box.cag.combase.de> Hi, I support Maurizio's argument: If your are in need of quotes within quotes ("I said \"Quote me!\" to make my point.") or something similar that has some kind of structure, you probably are in need of an abstraction to your use case rather than a language change: "I said " + quote("Quote me!") + " to make my point." About the platform dependency: Maybe I'm missing something here, but I don't see how the compiling platform can even effect or alter a literal String expression anyway. The line-break already is in the source code, and it is Unix/Windows/Mac depending on what delimiter your IDE chose to put down when you hit enter (or which one you told it to choose). Every reasonable compiler should come up with the same result independent of the compiling platform, which is to use the same line-break as in the source. If your source changed during the transfer from OSix to wOS, then that's the problem. My IDE supports the display of typographic (hidden) characters and the explicit line-break conversion between the major standards. How about yours? If anything, I would like string literals to support the in-lining of escape-sequences and/or line-wrapping support by means of a trailing backslash to improve readability of code: "This is a single-line string literal although it \ has 2 lines in the source to illustrate my point." However, the major question with multi-line string literals is, how the broken lines fit into the indention structure of the surrounding context (indention is not a syntax rule but merely a convention), and how they will improve or impair the overall readability: public class SomeClass { private final static String MULTI_LINE = "This is a deranged multi- line string literal."; //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ --> whitespace hell ??? public static class SubClass { public void doSomething() { final String label = "this is the first line; this is the second line; this is the third line; this is the last line"; this is an error; } public void doSomethingElse() { final String label = " // this label will confuse you... this.confuse(label); } public void confuse(String confusion) { System.out.println(confusion); } // "; // end of label } } } Regards, Kai Am Montag, den 08.08.2011, 09:16 +0100 schrieb Maurizio Cimadamore: > On 07/08/11 14:54, Artur Biesiadowski wrote: > > Because it is not only about multiline literals, it is about avoiding > > escaping common expressions - in particular, "" delimited strings. > > > > This is why somebody was discussing 'single line multiline string > > literal' here ;) > Hi, > it seems to me that we are asking for a silver bullet that solves all > our string-related problems; how much would we need escaping for > delimited strings if we had explicit syntax support for XML, JSON (etc.) > literals (possibly checked at compile-time against a schema?) - at the > end of the day, a string is a string - there's nothing much the compiler > can do about it; on the other hand, most of the examples of multiline > strings I've seen in this discussion do have a 'structure' that can be > checked. > > Maurizio > > Regards, > > Artur Biesiadowski > > > > On 07/08/2011 13:36, R?mi Forax wrote: > >> An why not using " ? > >> why do we need a different syntax for single line and multiple lines > >> string literals ? > >> > > > > From mcnepp02 at googlemail.com Mon Aug 8 10:15:41 2011 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Mon, 08 Aug 2011 19:15:41 +0200 Subject: Defender-methods: A chance to finally retrofit Cloneable with clone method? Message-ID: <4E4019BD.8060805@googlemail.com> I was wondering whether it would be possible to retrofit the interface java.lang.Cloneable with a public clone method, now that defender-methods will be available. Even after living without a standard cloning mechanism im Java for 10+ years, I'd still love to have one! For the default implementation, I can see the following choices: 1. Invoke the built-in cloning mechanism through Object.clone(). Since a static defender method could not directly invoke Object.clone through its argument, it would have to be either native or delegate to some kind of native "System.systemClone" method to achive this. 2. Throw CloneNotSupportedException. 3. Throw UnsupportedOperationException. 4. Return the object itself (shallow clone). Personally, I think 2.) would be by far the worst choice, because it would make it necessary for the interface to declare the checked CloneNotSupportedException, somehow negating the whole purpose of having a clone method in an interface at all! What do the experts think? From pbenedict at apache.org Mon Aug 8 10:53:27 2011 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 8 Aug 2011 12:53:27 -0500 Subject: Defender-methods: A chance to finally retrofit Cloneable with clone method? In-Reply-To: <4E4019BD.8060805@googlemail.com> References: <4E4019BD.8060805@googlemail.com> Message-ID: I think you should avoid the Cloneable interface at all costs. It was a bad idea from the beginning. I don't think it's possible force a universal definition on cloning onto application developers (there are too many differing needs), which is probably why this interface is hardly used. On Mon, Aug 8, 2011 at 12:15 PM, Gernot Neppert wrote: > I was wondering whether it would be possible to retrofit the interface > java.lang.Cloneable with a public clone method, now that > defender-methods will be available. > Even after living without a standard cloning mechanism im Java for 10+ > years, I'd still love to have one! > > For the default implementation, I can see the following choices: > > 1. Invoke the built-in cloning mechanism through Object.clone(). Since a > static defender method could not directly invoke Object.clone through > its argument, it would have to be either native or delegate to some kind > of ?native "System.systemClone" method to achive this. > > 2. Throw CloneNotSupportedException. > > 3. Throw UnsupportedOperationException. > > 4. Return the object itself (shallow clone). > > Personally, I think 2.) would be by far the worst choice, because it > would make it necessary for the interface to declare the checked > CloneNotSupportedException, somehow negating the whole purpose of having > a clone method in an interface at all! > > What do the experts think? > > From joe.darcy at oracle.com Mon Aug 8 11:07:36 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 08 Aug 2011 11:07:36 -0700 Subject: Defender-methods: A chance to finally retrofit Cloneable with clone method? In-Reply-To: References: <4E4019BD.8060805@googlemail.com> Message-ID: <4E4025E8.5070907@oracle.com> Hello. There is a long, sad story behind why Cloneable is only a marker interface; IIRC, at least some of that story is recounted in "Effective Java." In any case, I do not expect defenders to be used to retrofit a clone method to Cloneable. -Joe On 8/8/2011 10:53 AM, Paul Benedict wrote: > I think you should avoid the Cloneable interface at all costs. It was > a bad idea from the beginning. I don't think it's possible force a > universal definition on cloning onto application developers (there are > too many differing needs), which is probably why this interface is > hardly used. > > On Mon, Aug 8, 2011 at 12:15 PM, Gernot Neppert wrote: >> I was wondering whether it would be possible to retrofit the interface >> java.lang.Cloneable with a public clone method, now that >> defender-methods will be available. >> Even after living without a standard cloning mechanism im Java for 10+ >> years, I'd still love to have one! >> >> For the default implementation, I can see the following choices: >> >> 1. Invoke the built-in cloning mechanism through Object.clone(). Since a >> static defender method could not directly invoke Object.clone through >> its argument, it would have to be either native or delegate to some kind >> of native "System.systemClone" method to achive this. >> >> 2. Throw CloneNotSupportedException. >> >> 3. Throw UnsupportedOperationException. >> >> 4. Return the object itself (shallow clone). >> >> Personally, I think 2.) would be by far the worst choice, because it >> would make it necessary for the interface to declare the checked >> CloneNotSupportedException, somehow negating the whole purpose of having >> a clone method in an interface at all! >> >> What do the experts think? >> >> From mcnepp02 at googlemail.com Tue Aug 9 22:50:37 2011 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Wed, 10 Aug 2011 07:50:37 +0200 Subject: Defender-methods: A chance to finally retrofit Cloneable with clone method? In-Reply-To: <4E4025E8.5070907@oracle.com> References: <4E4019BD.8060805@googlemail.com> <4E4025E8.5070907@oracle.com> Message-ID: <4E421C2D.2060304@googlemail.com> Am 08.08.2011 20:07, schrieb Joe Darcy: > Hello. > > There is a long, sad story behind why Cloneable is only a marker > interface; IIRC, at least some of that story is recounted in "Effective > Java." All that I ever read about the history of Cloneable said it was a mistake not to include the clone() method in the interface and that it could not be retrofitted compatibly. (See, for example, the bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4098033) Well, now (with defender methods) we can retrofit it! > In any case, I do not expect defenders to be used to retrofit a clone > method to Cloneable. > I don't get the intention of that sentence. Do you expect other means to be used to retrofit a clone method? Or do you not expect Cloneable ever to be fixed? Or is it a hint about what you would endorse or not endorse? From abies at adres.pl Wed Aug 10 00:50:30 2011 From: abies at adres.pl (Artur Biesiadowski) Date: Wed, 10 Aug 2011 08:50:30 +0100 Subject: Defender-methods: A chance to finally retrofit Cloneable with clone method? In-Reply-To: <4E421C2D.2060304@googlemail.com> References: <4E4019BD.8060805@googlemail.com> <4E4025E8.5070907@oracle.com> <4E421C2D.2060304@googlemail.com> Message-ID: <4E423846.5080006@adres.pl> On 10/08/2011 06:50, Gernot Neppert wrote: > Well, now (with defender methods) we can retrofit it! > How are you going to do it to keep following class compiling ? public class Test implements Cloneable{ protected Object clone() { return new Test(); } } Regards, Artur Biesiadowski From frederic.martini at gmail.com Thu Aug 18 05:11:40 2011 From: frederic.martini at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Martini?=) Date: Thu, 18 Aug 2011 14:11:40 +0200 Subject: PROPOSAL: Named and Optional parameters, "Java-style" Message-ID: Hello, (before to start, sorry for my poor english) I'd like to propose the implementation of named & optional method parameters, similar to the Java 5.0 varargs. PROPOSAL: Named and Optional parameters, "Java-style" AUTHOR(S): Fr?d?ric Martini OVERVIEW FEATURE SUMMARY: Named parameters free you from the need to remember or to look up the order of parameters in the parameter lists of called methods. The value for each parameter will be specified by name (instead of by order). Optional parameters allow methods to specity a default value for parameters, that allow caller to omit theses. If no value is sent for theses parameters, the default value is used. MAJOR ADVANTAGE: Generally, this is implemented via syntactic sugar and affects only the compilation step. But this would make a lot of limitation in a language like Java : * The widespread use of "Named parameter" will put the parameter names in the method's signature. So any changes at this level could potentially break compatibility. * The use of "Optional parameter" limits the method's evolution : Adding an optional parameter causes incompatibilities (break at runtime). Default values are limited to constant, and fixed at compile-time. Their changes involve a recompilation of callers codes, and they can not be modified by overriding... (See reference "Use Optional Parameters to Minimize Method Overloads" for d?tail of these problems on C# implementation) This proposal opts for another approach similar to the Java 5.0 varargs, which impacts both the compilation and runtime steps : all "named & optional" parameters will be stored in a sort of map, an retrieved or set to default-value at runtime . MAJOR BENEFIT: Allows the creation of clearer and precise API. They can easily replace most of "builder pattern" and method's overloading, using a single method... Without any impact on existing code or method signature that don't use "named & optional parameters". MAJOR DISADVANTAGE: Method's call will be slowest when using named & optional args. ALTERNATIVES: Method's overloading and/or "builder pattern". But this is boring :( EXAMPLES SIMPLE EXAMPLE: // Method declaration // The named & optional parameters are distinguished by brackets {} public void method(int standardArg, {int namedArg, int namedAndOptionalArg=0}) { System.out.printf("%d;%d;%d", standardArg, namedArg, namedAndOptionalArg); } // Method call // The named & optional parameters MUST be called by name. method( 1, namedArg:2, namedAndOptionalArg=3 ); // output: 1;2;3 method( 1, namedAndOptionalArg=3, namedArg:2 ); // output: 1;2;3 method( 1, namedArg:2 ); // output: 1;2;0 // Of course compiler will check that the call is correct : // + Non-optional parameters MUST be present. // + Invalid parameter's name will generate error. method( 1 ); // COMPIL ERROR : "namedArg" is required method( 1, namedArg:2, invalidName:3 ); // COMPIL ERROR : "invalidName" is not a valid name ADVANCED EXAMPLE: // Optional parameters can use contant OR statement : public void method({String separator=";", Locale locale=Locale.getDefault(), String lineSeparator=System.getProperty("line.separator")}) { } // Method declaration can use varargs, that allow the usage of any name/value without compile error // Each implementation can check for theses parameters... public void method({String filename, ...} options); // all these call are valid : method(filename:"file.txt"); method(filename:"file.txt", encoding:"utf-8"); method(filename:"file.txt", encoding:"utf-8", append:true); method(filename:"file.txt", encoding:"utf-8", append:true, anything:anyValue); DETAILS SPECIFICATION: The use of Named & Optionnal paramters MUST be specified on the method signature. Named parameters will be distinguished by brackets {}, and MUST be passed by name at call time. Any named parameter can have a default value, that can be a compile-time constant OR a statement. // exemple01 : use of named parameter : public void exemple01({int foo, String bar}) { System.out.printf("exemple01(foo=%d, bar=%s)%n", foo, bar); } // exemple02 : use of named & optional parameter using constant : public void exemple02({int foo=30, String bar="hi"}) { System.out.printf("exemple02(foo=%d, bar=%s)%n", foo, bar); } // exemple03 : use of named & optional parameter using constant AND statement : public void exemple03({int foo=30, String bar=System.getProperty("os.name")}) { System.out.printf("exemple03(foo=%d, bar=%s)%n", foo, bar); } // exemple04 : use of named & optional parameter using constant AND statement, // AND use varargs to allow any name/value parameters. public void exemple04({int foo=30, String bar=System.getProperty("os.name"), ...} args) { System.out.printf("exemple04(foo=%d, bar=%s) + %s%n", foo, bar, args); } // Calling example : exemple01(foo:10, bar:"hello"); System.out.println(); exemple02(foo:10, bar:"hello"); exemple02(foo:10); exemple02(bar:"hello"); exemple02(); System.out.println(); exemple03(foo:10, bar:"hello"); exemple03(foo:10); exemple03(bar:"hello"); exemple03(); System.out.println(); exemple04(foo:10, bar:"hello", any=100, name="value"); COMPILATION: At compile time, each "named & optional" method will be converted to a method using a parameters of type "OptArgs". The type is contains a Map with all parameters name/value. Theses methods will be annoted to describe parameters names/types, and a basic code willbe generated to initialise parameters as local variables // exemple01 : use of named parameter : @OptArgsInfo({ @OptArg(name="foo", type=int.class), @OptArg(name="bar", type=String.class), }) public void exemple01(OptArgs $generated$) { final int foo = $generated$.retrieve("foo", int.class); final String bar = $generated$.retrieve("bar", String.class); System.out.printf("exemple01(foo=%d, bar=%s)%n", foo, bar); } The annotation @OptArgsInfo will describe all parameters that the method can receive in the "OptArgs" parameters. The "OptArgs" object contains a retrieve(String,Class) method in order to get the parameter value for the specified name/type. // exemple02 : use of named & optional parameter using constant : @OptArgsInfo(value={ @OptArg(name="foo", type=int.class, optional=true), @OptArg(name="bar", type=String.class, optional=true), }) public void exemple02(OptArgs $generated$) { final int foo = $generated$.retrieve("foo", int.class, 30); final String bar = $generated$.retrieve("bar", String.class, "hi"); System.out.printf("exemple02(foo=%d, bar=%s)%n", foo, bar); } Here the named parameters are optionals (because they have a default value). If parameter is absent, the method retrieve(String,Class,T) return the default constant value. // exemple03 : use of named & optional parameter using constant AND statement : @OptArgsInfo(value={ @OptArg(name="foo", type=int.class, optional=true), @OptArg(name="bar", type=String.class, optional=true), }) public void exemple03(OptArgs $generated$) { final int foo = $generated$.retrieve("foo", int.class, 30); final String bar = $generated$.contains("bar", String.class) ? $generated$.retrieve("bar", String.class) : System.getProperty("os.name"); System.out.printf("exemple03(foo=%d, bar=%s)%n", foo, bar); } For optional parameters that use statement as default value, we use the ternary operator "?" to correctly initialize the variable when parameter is absent. // exemple04 : use of named & optional parameter using constant AND statement, // AND use varargs to allow any name/value parameters. @OptArgsInfo(acceptUnknownArgs=true, value={ @OptArg(name="foo", type=int.class, optional=true), @OptArg(name="bar", type=String.class, optional=true), }) public void exemple04(OptArgs args) { final int foo = args.retrieve("foo", int.class, 30); final String bar = args.contains("bar", String.class) ? args.retrieve("bar", String.class) : System.getProperty("os.name"); System.out.printf("exemple04(foo=%d, bar=%s) + %s%n", foo, bar, args); } The annotation contains the value acceptUnknownArgs=true in order to inform the compiler that this method accept any name/value in addition to its declared parameters. In the body of the method, it may be possible to use the object "OptArg" in order to access to these additional parameters... // Calling example : exemple01(OptArgs.make("foo", 10, "bar", "hello")); System.out.println(); exemple02(OptArgs.make("foo", 10, "bar", "hello")); exemple02(OptArgs.make("foo", 10)); exemple02(OptArgs.make("bar", "hello")); exemple02(OptArgs.empty()); System.out.println(); exemple03(OptArgs.make("foo", 10, "bar", "hello")); exemple03(OptArgs.make("foo", 10)); exemple03(OptArgs.make("bar", "hello")); exemple03(OptArgs.empty()); System.out.println(); exemple04(OptArgs.make("foo", 10, "bar", "hello", "any", 100, "name", "value")); This solution propose a less-disturbing choise : * The "named and optional" parameters block must be at the end of the method's parameter list (like varargs). * Named parameters can only be used with specific method that contains a "named & optional" block. * There are no impact on method that don't use "named & optional parameters". * We can override an "named and optional" method. * We can add an optional parameter to an existant "named and optional" method (or on an overrided method). * We can remove an optional parameter on an overrided method (if present it will be ignored) * We can modify the default value of an optional parameter withour having to recompile all the caller's code. * Renaming a "named parameter", removing a default-value or adding a non-optional parameter is an incompatible change. TESTING: A basic implementation can be found here (source-code) : http://adiguba.developpez.com/coin-optargs/ LIBRARY SUPPORT: No. REFLECTIVE APIS: java.lang.reflect.Method and java.lang.reflect.Constructor could be enhanced with new methods that return informations about "named & optional parameters" : isOptArgs() return true if method use "named & optional parameters" getOptArgs() return an array of OptArg annotation, that describe the "named & optional parameters". isOptArgsAcceptUnknownArgs() return this if method accept unknown name/value args (varargs-like). OTHER CHANGES: Javadoc must be updated in order to accept @param that match the named parameters, and indicate optional parameter. MIGRATION: This is a new syntax for new method. COMPATIBILITY BREAKING CHANGES: No (new syntax). EXISTING PROGRAMS: The changes required by this feature should be transparent to existing source and class files. It only consist to a method with a new and specific type. Overriding is still possible. REFERENCES Use Optional Parameters to Minimize Method Overloads : http://msdn.microsoft.com/en-us/vcsharp/ff467291 EXISTING BUGS: ? URL FOR PROTOTYPE : A basic implementation with demo that represent the code generated by the compileur (I do not have sufficient expertise to offer a modified version of javac) : http://adiguba.developpez.com/coin-optargs/ Thanks for reading :) From pbenedict at apache.org Thu Aug 18 08:06:41 2011 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 18 Aug 2011 10:06:41 -0500 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: References: Message-ID: I believe recording the name of argument methods would require a class file update. That might be against the spirit of a "coin" enhancement. 2011/8/18 Fr?d?ric Martini : > Hello, > > (before to start, sorry for my poor english) > > > I'd like to propose the implementation of named & optional method > parameters, similar to the Java 5.0 varargs. > > > > > PROPOSAL: Named and Optional parameters, "Java-style" > > AUTHOR(S): Fr?d?ric Martini > > OVERVIEW > > FEATURE SUMMARY: > > Named parameters free you from the need to remember or to look up the > order of parameters in the parameter lists of called methods. The > value for each parameter will be specified by name (instead of by > order). > > > Optional parameters allow methods to specity a default value for > parameters, that allow caller to omit theses. If no value is sent for > theses parameters, the default value is used. > > > > MAJOR ADVANTAGE: > > Generally, this is implemented via syntactic sugar and affects only > the compilation step. But this would make a lot of limitation in a > language like Java : > > ?* The widespread use of "Named parameter" will put the parameter > names in the method's signature. So any changes at this level could > potentially break compatibility. > > ?* The use of "Optional parameter" limits the method's evolution : > Adding an optional parameter causes incompatibilities (break at runtime). > Default values are limited to constant, and fixed at compile-time. > Their changes involve a recompilation of callers codes, and they can > not be modified by overriding... > > (See reference "Use Optional Parameters to Minimize Method Overloads" > for d?tail of these problems on C# implementation) > > > This proposal opts for another approach similar to the Java 5.0 > varargs, which impacts both the compilation and runtime steps : all > "named & optional" parameters will be stored in a sort of map, an > retrieved or set to default-value at runtime . > > > > > MAJOR BENEFIT: > > Allows the creation of clearer and precise API. > They can easily replace most of "builder pattern" and method's > overloading, using a single method... > > Without any impact on existing code or method signature that don't use > "named & optional parameters". > > > MAJOR DISADVANTAGE: > > Method's call will be slowest when using named & optional args. > > > > ALTERNATIVES: > > Method's overloading and/or "builder pattern". But this is boring :( > > > > > EXAMPLES > > SIMPLE EXAMPLE: > > // Method declaration > // The named & optional parameters are distinguished by brackets {} > > public void method(int standardArg, {int namedArg, int namedAndOptionalArg=0}) { > ? ? ? ?System.out.printf("%d;%d;%d", standardArg, namedArg, namedAndOptionalArg); > } > > > // Method call > // The named & optional parameters MUST be called by name. > > method( 1, namedArg:2, namedAndOptionalArg=3 ); // output: 1;2;3 > method( 1, namedAndOptionalArg=3, namedArg:2 ); // output: 1;2;3 > method( 1, namedArg:2 ); ? ? ? ? ? ? ? ? ? ? ? ?// output: 1;2;0 > > // Of course compiler will check that the call is correct : > // + Non-optional parameters MUST be present. > // + Invalid parameter's name will generate error. > > method( 1 ); ? ? ? ? ? ? ? ? ? ? ? ? ? ?// COMPIL ERROR : "namedArg" is required > method( 1, namedArg:2, invalidName:3 ); // COMPIL ERROR : > "invalidName" is not a valid name > > > > > ADVANCED EXAMPLE: > > > // Optional parameters can use contant OR statement : > > public void method({String separator=";", Locale > locale=Locale.getDefault(), String > lineSeparator=System.getProperty("line.separator")}) { > > } > > > // Method declaration can use varargs, that allow the usage of any > name/value without compile error > // Each implementation can check for theses parameters... > > public void method({String filename, ...} options); > > // all these call are valid : > method(filename:"file.txt"); > method(filename:"file.txt", encoding:"utf-8"); > method(filename:"file.txt", encoding:"utf-8", append:true); > method(filename:"file.txt", encoding:"utf-8", append:true, anything:anyValue); > > > DETAILS > > SPECIFICATION: > > > The use of Named & Optionnal paramters MUST be specified on the method > signature. > Named parameters will be distinguished by brackets {}, and MUST be > passed by name at call time. > Any named parameter can have a default value, that can be a > compile-time constant OR a statement. > > > // exemple01 : use of named parameter : > > public void exemple01({int foo, String bar}) { > ? ? ? ?System.out.printf("exemple01(foo=%d, bar=%s)%n", foo, bar); > } > > // exemple02 : use of named & optional parameter using constant : > > public void exemple02({int foo=30, String bar="hi"}) { > ? ? ? ?System.out.printf("exemple02(foo=%d, bar=%s)%n", foo, bar); > } > > // exemple03 : use of named & optional parameter using constant AND statement : > > public void exemple03({int foo=30, String bar=System.getProperty("os.name")}) { > ? ? ? ?System.out.printf("exemple03(foo=%d, bar=%s)%n", foo, bar); > } > > > // exemple04 : use of named & optional parameter using constant AND statement, > // ? ? ? ? ? ? AND use varargs to allow any name/value parameters. > > public void exemple04({int foo=30, String > bar=System.getProperty("os.name"), ...} args) { > ? ? ? ?System.out.printf("exemple04(foo=%d, bar=%s) + %s%n", foo, bar, args); > } > > > // Calling example : > > exemple01(foo:10, bar:"hello"); > > System.out.println(); > > exemple02(foo:10, bar:"hello"); > exemple02(foo:10); > exemple02(bar:"hello"); > exemple02(); > > System.out.println(); > > exemple03(foo:10, bar:"hello"); > exemple03(foo:10); > exemple03(bar:"hello"); > exemple03(); > > System.out.println(); > > exemple04(foo:10, bar:"hello", any=100, name="value"); > > > COMPILATION: > > At compile time, each "named & optional" method will be converted to a > method using a parameters of type "OptArgs". The type is contains a > Map with all parameters name/value. Theses methods will be annoted to > describe parameters names/types, and a basic code willbe generated to > initialise parameters as local variables > > > > > // exemple01 : use of named parameter : > > @OptArgsInfo({ > ? ? ? ?@OptArg(name="foo", type=int.class), > ? ? ? ?@OptArg(name="bar", type=String.class), > }) > public void exemple01(OptArgs $generated$) { > ? ? ? ?final int foo = $generated$.retrieve("foo", int.class); > ? ? ? ?final String bar = $generated$.retrieve("bar", String.class); > > ? ? ? ?System.out.printf("exemple01(foo=%d, bar=%s)%n", foo, bar); > } > > > The annotation @OptArgsInfo will describe all parameters that the > method can receive in the "OptArgs" parameters. > The "OptArgs" object contains a retrieve(String,Class) method in order > to get the parameter value for the specified name/type. > > > > > // exemple02 : use of named & optional parameter using constant : > > @OptArgsInfo(value={ > ? ? ? ?@OptArg(name="foo", type=int.class, optional=true), > ? ? ? ?@OptArg(name="bar", type=String.class, optional=true), > }) > public void exemple02(OptArgs $generated$) { > ? ? ? ?final int foo = $generated$.retrieve("foo", int.class, 30); > ? ? ? ?final String bar = $generated$.retrieve("bar", String.class, "hi"); > > ? ? ? ?System.out.printf("exemple02(foo=%d, bar=%s)%n", foo, bar); > } > > > Here the named parameters are optionals (because they have a default value). > If parameter is absent, the method retrieve(String,Class,T) return > the default constant value. > > > > > // exemple03 : use of named & optional parameter using constant AND statement : > > @OptArgsInfo(value={ > ? ? ? ?@OptArg(name="foo", type=int.class, optional=true), > ? ? ? ?@OptArg(name="bar", type=String.class, optional=true), > }) > public void exemple03(OptArgs $generated$) { > ? ? ? ?final int foo = $generated$.retrieve("foo", int.class, 30); > ? ? ? ?final String bar = $generated$.contains("bar", String.class) > ? ? ? ? ? ? ? ?? $generated$.retrieve("bar", String.class) > ? ? ? ? ? ? ? ?: System.getProperty("os.name"); > > ? ? ? ?System.out.printf("exemple03(foo=%d, bar=%s)%n", foo, bar); > } > > > For optional parameters that use statement as default value, we use > the ternary operator "?" to correctly initialize the variable when > parameter is absent. > > > > > > // exemple04 : use of named & optional parameter using constant AND statement, > // ? ? ? ? ? ? AND use varargs to allow any name/value parameters. > > @OptArgsInfo(acceptUnknownArgs=true, value={ > ? ? ? ?@OptArg(name="foo", type=int.class, optional=true), > ? ? ? ?@OptArg(name="bar", type=String.class, optional=true), > }) > public void exemple04(OptArgs args) { > ? ? ? ?final int foo = args.retrieve("foo", int.class, 30); > ? ? ? ?final String bar = args.contains("bar", String.class) > ? ? ? ? ? ? ? ?? args.retrieve("bar", String.class) > ? ? ? ? ? ? ? ?: System.getProperty("os.name"); > > ? ? ? ?System.out.printf("exemple04(foo=%d, bar=%s) + %s%n", foo, bar, args); > } > > > The annotation contains the value acceptUnknownArgs=true in order to > inform the compiler that this method accept any name/value in addition > to its declared parameters. In the body of the method, it may be > possible to use the object "OptArg" in order to access to these > additional parameters... > > > > > > // Calling example : > > > exemple01(OptArgs.make("foo", 10, "bar", "hello")); > > System.out.println(); > > exemple02(OptArgs.make("foo", 10, "bar", "hello")); > exemple02(OptArgs.make("foo", 10)); > exemple02(OptArgs.make("bar", "hello")); > exemple02(OptArgs.empty()); > > System.out.println(); > > exemple03(OptArgs.make("foo", 10, "bar", "hello")); > exemple03(OptArgs.make("foo", 10)); > exemple03(OptArgs.make("bar", "hello")); > exemple03(OptArgs.empty()); > > System.out.println(); > > exemple04(OptArgs.make("foo", 10, "bar", "hello", "any", 100, "name", "value")); > > > > > > This solution propose a less-disturbing choise : > > > ?* The "named and optional" parameters block must be at the end of the > method's parameter list (like varargs). > ?* Named parameters can only be used with specific method that > contains a "named & optional" block. > ?* There are no impact on method that don't use "named & optional parameters". > ?* We can override an "named and optional" method. > ?* We can add an optional parameter to an existant "named and > optional" method (or on an overrided method). > ?* We can remove an optional parameter on an overrided method (if > present it will be ignored) > ?* We can modify the default value of an optional parameter withour > having to recompile all the caller's code. > ?* Renaming a "named parameter", removing a default-value or adding a > non-optional parameter is an incompatible change. > > > > TESTING: > > > A basic implementation can be found here (source-code) : > http://adiguba.developpez.com/coin-optargs/ > > > LIBRARY SUPPORT: > > No. > > REFLECTIVE APIS: > > java.lang.reflect.Method and java.lang.reflect.Constructor could be > enhanced with new methods that return informations about "named & > optional parameters" : > > > isOptArgs() > ? ? ? ?return true if method use "named & optional parameters" > > getOptArgs() > ? ? ? ?return an array of OptArg annotation, that describe the "named & > optional parameters". > > isOptArgsAcceptUnknownArgs() > ? ? ? ?return this if method accept unknown name/value args (varargs-like). > > > OTHER CHANGES: > > Javadoc must be updated in order to accept @param that match the named > parameters, and indicate optional parameter. > > MIGRATION: > > This is a new syntax for new method. > > > COMPATIBILITY > > BREAKING CHANGES: > > No (new syntax). > > > EXISTING PROGRAMS: > > The changes required by this feature should be transparent to existing > source and class files. > It only consist to a method with a new and specific type. > > Overriding is still possible. > > REFERENCES > > Use Optional Parameters to Minimize Method Overloads : > http://msdn.microsoft.com/en-us/vcsharp/ff467291 > > > EXISTING BUGS: > > ? > > URL FOR PROTOTYPE : > > A basic implementation with demo that represent the code generated by > the compileur (I do not have sufficient expertise to offer a modified > version of javac) : > http://adiguba.developpez.com/coin-optargs/ > > > > > > > Thanks for reading :) > > From brian.goetz at oracle.com Thu Aug 18 09:19:42 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 18 Aug 2011 12:19:42 -0400 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: References: Message-ID: <4E4D3B9E.3040308@oracle.com> Paul is right, that classfile changes definitely push something out of the "small" bucket. However, "parameter names in class files" is a long-standing request from both the enterprise and IDE crowds, and one that might possibly show up in a future version of Java, and if it did, there would be a place to record various parameter-specific information. But, even if it did, another thing that makes a proposal "big" is "touching method overload resolution rules". And the essence of this proposal is adding another layer of complexity to method overload resolution. On 8/18/2011 11:06 AM, Paul Benedict wrote: > I believe recording the name of argument methods would require a class > file update. That might be against the spirit of a "coin" enhancement. > > 2011/8/18 Fr?d?ric Martini: >> Hello, >> >> (before to start, sorry for my poor english) >> >> >> I'd like to propose the implementation of named& optional method >> parameters, similar to the Java 5.0 varargs. >> >> >> >> >> PROPOSAL: Named and Optional parameters, "Java-style" >> >> AUTHOR(S): Fr?d?ric Martini >> >> OVERVIEW >> >> FEATURE SUMMARY: >> >> Named parameters free you from the need to remember or to look up the >> order of parameters in the parameter lists of called methods. The >> value for each parameter will be specified by name (instead of by >> order). >> >> >> Optional parameters allow methods to specity a default value for >> parameters, that allow caller to omit theses. If no value is sent for >> theses parameters, the default value is used. >> >> >> >> MAJOR ADVANTAGE: >> >> Generally, this is implemented via syntactic sugar and affects only >> the compilation step. But this would make a lot of limitation in a >> language like Java : >> >> * The widespread use of "Named parameter" will put the parameter >> names in the method's signature. So any changes at this level could >> potentially break compatibility. >> >> * The use of "Optional parameter" limits the method's evolution : >> Adding an optional parameter causes incompatibilities (break at runtime). >> Default values are limited to constant, and fixed at compile-time. >> Their changes involve a recompilation of callers codes, and they can >> not be modified by overriding... >> >> (See reference "Use Optional Parameters to Minimize Method Overloads" >> for d?tail of these problems on C# implementation) >> >> >> This proposal opts for another approach similar to the Java 5.0 >> varargs, which impacts both the compilation and runtime steps : all >> "named& optional" parameters will be stored in a sort of map, an >> retrieved or set to default-value at runtime . >> >> >> >> >> MAJOR BENEFIT: >> >> Allows the creation of clearer and precise API. >> They can easily replace most of "builder pattern" and method's >> overloading, using a single method... >> >> Without any impact on existing code or method signature that don't use >> "named& optional parameters". >> >> >> MAJOR DISADVANTAGE: >> >> Method's call will be slowest when using named& optional args. >> >> >> >> ALTERNATIVES: >> >> Method's overloading and/or "builder pattern". But this is boring :( >> >> >> >> >> EXAMPLES >> >> SIMPLE EXAMPLE: >> >> // Method declaration >> // The named& optional parameters are distinguished by brackets {} >> >> public void method(int standardArg, {int namedArg, int namedAndOptionalArg=0}) { >> System.out.printf("%d;%d;%d", standardArg, namedArg, namedAndOptionalArg); >> } >> >> >> // Method call >> // The named& optional parameters MUST be called by name. >> >> method( 1, namedArg:2, namedAndOptionalArg=3 ); // output: 1;2;3 >> method( 1, namedAndOptionalArg=3, namedArg:2 ); // output: 1;2;3 >> method( 1, namedArg:2 ); // output: 1;2;0 >> >> // Of course compiler will check that the call is correct : >> // + Non-optional parameters MUST be present. >> // + Invalid parameter's name will generate error. >> >> method( 1 ); // COMPIL ERROR : "namedArg" is required >> method( 1, namedArg:2, invalidName:3 ); // COMPIL ERROR : >> "invalidName" is not a valid name >> >> >> >> >> ADVANCED EXAMPLE: >> >> >> // Optional parameters can use contant OR statement : >> >> public void method({String separator=";", Locale >> locale=Locale.getDefault(), String >> lineSeparator=System.getProperty("line.separator")}) { >> >> } >> >> >> // Method declaration can use varargs, that allow the usage of any >> name/value without compile error >> // Each implementation can check for theses parameters... >> >> public void method({String filename, ...} options); >> >> // all these call are valid : >> method(filename:"file.txt"); >> method(filename:"file.txt", encoding:"utf-8"); >> method(filename:"file.txt", encoding:"utf-8", append:true); >> method(filename:"file.txt", encoding:"utf-8", append:true, anything:anyValue); >> >> >> DETAILS >> >> SPECIFICATION: >> >> >> The use of Named& Optionnal paramters MUST be specified on the method >> signature. >> Named parameters will be distinguished by brackets {}, and MUST be >> passed by name at call time. >> Any named parameter can have a default value, that can be a >> compile-time constant OR a statement. >> >> >> // exemple01 : use of named parameter : >> >> public void exemple01({int foo, String bar}) { >> System.out.printf("exemple01(foo=%d, bar=%s)%n", foo, bar); >> } >> >> // exemple02 : use of named& optional parameter using constant : >> >> public void exemple02({int foo=30, String bar="hi"}) { >> System.out.printf("exemple02(foo=%d, bar=%s)%n", foo, bar); >> } >> >> // exemple03 : use of named& optional parameter using constant AND statement : >> >> public void exemple03({int foo=30, String bar=System.getProperty("os.name")}) { >> System.out.printf("exemple03(foo=%d, bar=%s)%n", foo, bar); >> } >> >> >> // exemple04 : use of named& optional parameter using constant AND statement, >> // AND use varargs to allow any name/value parameters. >> >> public void exemple04({int foo=30, String >> bar=System.getProperty("os.name"), ...} args) { >> System.out.printf("exemple04(foo=%d, bar=%s) + %s%n", foo, bar, args); >> } >> >> >> // Calling example : >> >> exemple01(foo:10, bar:"hello"); >> >> System.out.println(); >> >> exemple02(foo:10, bar:"hello"); >> exemple02(foo:10); >> exemple02(bar:"hello"); >> exemple02(); >> >> System.out.println(); >> >> exemple03(foo:10, bar:"hello"); >> exemple03(foo:10); >> exemple03(bar:"hello"); >> exemple03(); >> >> System.out.println(); >> >> exemple04(foo:10, bar:"hello", any=100, name="value"); >> >> >> COMPILATION: >> >> At compile time, each "named& optional" method will be converted to a >> method using a parameters of type "OptArgs". The type is contains a >> Map with all parameters name/value. Theses methods will be annoted to >> describe parameters names/types, and a basic code willbe generated to >> initialise parameters as local variables >> >> >> >> >> // exemple01 : use of named parameter : >> >> @OptArgsInfo({ >> @OptArg(name="foo", type=int.class), >> @OptArg(name="bar", type=String.class), >> }) >> public void exemple01(OptArgs $generated$) { >> final int foo = $generated$.retrieve("foo", int.class); >> final String bar = $generated$.retrieve("bar", String.class); >> >> System.out.printf("exemple01(foo=%d, bar=%s)%n", foo, bar); >> } >> >> >> The annotation @OptArgsInfo will describe all parameters that the >> method can receive in the "OptArgs" parameters. >> The "OptArgs" object contains a retrieve(String,Class) method in order >> to get the parameter value for the specified name/type. >> >> >> >> >> // exemple02 : use of named& optional parameter using constant : >> >> @OptArgsInfo(value={ >> @OptArg(name="foo", type=int.class, optional=true), >> @OptArg(name="bar", type=String.class, optional=true), >> }) >> public void exemple02(OptArgs $generated$) { >> final int foo = $generated$.retrieve("foo", int.class, 30); >> final String bar = $generated$.retrieve("bar", String.class, "hi"); >> >> System.out.printf("exemple02(foo=%d, bar=%s)%n", foo, bar); >> } >> >> >> Here the named parameters are optionals (because they have a default value). >> If parameter is absent, the method retrieve(String,Class,T) return >> the default constant value. >> >> >> >> >> // exemple03 : use of named& optional parameter using constant AND statement : >> >> @OptArgsInfo(value={ >> @OptArg(name="foo", type=int.class, optional=true), >> @OptArg(name="bar", type=String.class, optional=true), >> }) >> public void exemple03(OptArgs $generated$) { >> final int foo = $generated$.retrieve("foo", int.class, 30); >> final String bar = $generated$.contains("bar", String.class) >> ? $generated$.retrieve("bar", String.class) >> : System.getProperty("os.name"); >> >> System.out.printf("exemple03(foo=%d, bar=%s)%n", foo, bar); >> } >> >> >> For optional parameters that use statement as default value, we use >> the ternary operator "?" to correctly initialize the variable when >> parameter is absent. >> >> >> >> >> >> // exemple04 : use of named& optional parameter using constant AND statement, >> // AND use varargs to allow any name/value parameters. >> >> @OptArgsInfo(acceptUnknownArgs=true, value={ >> @OptArg(name="foo", type=int.class, optional=true), >> @OptArg(name="bar", type=String.class, optional=true), >> }) >> public void exemple04(OptArgs args) { >> final int foo = args.retrieve("foo", int.class, 30); >> final String bar = args.contains("bar", String.class) >> ? args.retrieve("bar", String.class) >> : System.getProperty("os.name"); >> >> System.out.printf("exemple04(foo=%d, bar=%s) + %s%n", foo, bar, args); >> } >> >> >> The annotation contains the value acceptUnknownArgs=true in order to >> inform the compiler that this method accept any name/value in addition >> to its declared parameters. In the body of the method, it may be >> possible to use the object "OptArg" in order to access to these >> additional parameters... >> >> >> >> >> >> // Calling example : >> >> >> exemple01(OptArgs.make("foo", 10, "bar", "hello")); >> >> System.out.println(); >> >> exemple02(OptArgs.make("foo", 10, "bar", "hello")); >> exemple02(OptArgs.make("foo", 10)); >> exemple02(OptArgs.make("bar", "hello")); >> exemple02(OptArgs.empty()); >> >> System.out.println(); >> >> exemple03(OptArgs.make("foo", 10, "bar", "hello")); >> exemple03(OptArgs.make("foo", 10)); >> exemple03(OptArgs.make("bar", "hello")); >> exemple03(OptArgs.empty()); >> >> System.out.println(); >> >> exemple04(OptArgs.make("foo", 10, "bar", "hello", "any", 100, "name", "value")); >> >> >> >> >> >> This solution propose a less-disturbing choise : >> >> >> * The "named and optional" parameters block must be at the end of the >> method's parameter list (like varargs). >> * Named parameters can only be used with specific method that >> contains a "named& optional" block. >> * There are no impact on method that don't use "named& optional parameters". >> * We can override an "named and optional" method. >> * We can add an optional parameter to an existant "named and >> optional" method (or on an overrided method). >> * We can remove an optional parameter on an overrided method (if >> present it will be ignored) >> * We can modify the default value of an optional parameter withour >> having to recompile all the caller's code. >> * Renaming a "named parameter", removing a default-value or adding a >> non-optional parameter is an incompatible change. >> >> >> >> TESTING: >> >> >> A basic implementation can be found here (source-code) : >> http://adiguba.developpez.com/coin-optargs/ >> >> >> LIBRARY SUPPORT: >> >> No. >> >> REFLECTIVE APIS: >> >> java.lang.reflect.Method and java.lang.reflect.Constructor could be >> enhanced with new methods that return informations about "named& >> optional parameters" : >> >> >> isOptArgs() >> return true if method use "named& optional parameters" >> >> getOptArgs() >> return an array of OptArg annotation, that describe the "named& >> optional parameters". >> >> isOptArgsAcceptUnknownArgs() >> return this if method accept unknown name/value args (varargs-like). >> >> >> OTHER CHANGES: >> >> Javadoc must be updated in order to accept @param that match the named >> parameters, and indicate optional parameter. >> >> MIGRATION: >> >> This is a new syntax for new method. >> >> >> COMPATIBILITY >> >> BREAKING CHANGES: >> >> No (new syntax). >> >> >> EXISTING PROGRAMS: >> >> The changes required by this feature should be transparent to existing >> source and class files. >> It only consist to a method with a new and specific type. >> >> Overriding is still possible. >> >> REFERENCES >> >> Use Optional Parameters to Minimize Method Overloads : >> http://msdn.microsoft.com/en-us/vcsharp/ff467291 >> >> >> EXISTING BUGS: >> >> ? >> >> URL FOR PROTOTYPE : >> >> A basic implementation with demo that represent the code generated by >> the compileur (I do not have sufficient expertise to offer a modified >> version of javac) : >> http://adiguba.developpez.com/coin-optargs/ >> >> >> >> >> >> >> Thanks for reading :) >> >> > From saeedtej at yahoo.com Sat Aug 20 12:16:44 2011 From: saeedtej at yahoo.com (saeed yousefi) Date: Sat, 20 Aug 2011 12:16:44 -0700 (PDT) Subject: multiline string/string literal without escape processing Message-ID: <1313867804.56025.YahooMailNeo@web111404.mail.gq1.yahoo.com> I think Java as a mature language should now have some missed features and one of them is multiline string/string literal without escape processing . it can really reduce lots of developer's efforts in writing multiline Strings . As you know in situations like JSON? it's very hard and error-prone to write code without using this feature . as another example consider you 're writing JS code and you should do lots of literal escaping . so as a Java developer , can I hope to see this feature for JDK8 ? saeed From tball at google.com Sat Aug 20 16:51:04 2011 From: tball at google.com (Tom Ball) Date: Sat, 20 Aug 2011 16:51:04 -0700 Subject: multiline string/string literal without escape processing In-Reply-To: <1313867804.56025.YahooMailNeo@web111404.mail.gq1.yahoo.com> References: <1313867804.56025.YahooMailNeo@web111404.mail.gq1.yahoo.com> Message-ID: There's a great language you should considering using that has built-in support for JS and JSON: JavaScript. Just because something can be written in Java doesn't mean that it necessarily should, as real engineers write code in the language most appropriate for the task before them (IMO). Another option is to put the text you're currently laboriously escaping into external resource files, and just read them in as needed. The advantage to keeping text in different files is that most editors and IDEs provide syntax-specific formatting, which makes it easier to write and mades errors easier to spot. JSON? Use a library to convert your data types instead of doing it by hand, as the overhead is minimal. Write unit tests for those data classes and you have a much more robust solution that scales much better than hand editing. Tom On Sat, Aug 20, 2011 at 12:16 PM, saeed yousefi wrote: > I think Java as a mature language should now have some missed features and > one of them is > multiline string/string literal without escape processing . it can really > reduce lots of developer's efforts in writing multiline Strings . > > As you know in situations like JSON it's very hard and error-prone to > write code without using this feature . > > as another example consider you 're writing JS code and you should do lots > of literal escaping . > > > so as a Java developer , can I hope to see this feature for JDK8 ? > > saeed > > From saeedtej at yahoo.com Sun Aug 21 03:48:36 2011 From: saeedtej at yahoo.com (saeed yousefi) Date: Sun, 21 Aug 2011 03:48:36 -0700 (PDT) Subject: multiline string/string literal without escape processing In-Reply-To: References: <1313867804.56025.YahooMailNeo@web111404.mail.gq1.yahoo.com> Message-ID: <1313923716.35795.YahooMailNeo@web111406.mail.gq1.yahoo.com> Hi Yes , I know I can put the text into external resources but it doesn't mean that there shouldn't be such facility in the language itself .? so for what strings exist ? There are lots of places where I want to return a short JSON response from server and I can do it with this feature. regards saeed ________________________________ From: Tom Ball To: saeed yousefi Cc: "coin-dev at openjdk.java.net" Sent: Sunday, August 21, 2011 4:21 AM Subject: Re: multiline string/string literal without escape processing There's a great language you should considering using that has built-in support for JS and JSON: ?JavaScript. ?Just because something can be written in Java doesn't mean that it necessarily should, as real engineers write code in the language most appropriate for the task before them (IMO). Another option is to put the text you're currently?laboriously?escaping into external resource files, and just read them in as needed. ?The advantage to keeping text in different files is that most editors and IDEs provide syntax-specific formatting, which makes it easier to write and mades errors easier to spot. ?JSON? ?Use a library to convert your data types instead of doing it by hand, as the overhead is minimal. ?Write unit tests for those data classes and you have a much more robust solution that scales much better than hand editing. Tom From forax at univ-mlv.fr Sun Aug 21 07:45:58 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 21 Aug 2011 16:45:58 +0200 Subject: multiline string/string literal without escape processing In-Reply-To: <1313923716.35795.YahooMailNeo@web111406.mail.gq1.yahoo.com> References: <1313867804.56025.YahooMailNeo@web111404.mail.gq1.yahoo.com> <1313923716.35795.YahooMailNeo@web111406.mail.gq1.yahoo.com> Message-ID: <4E511A26.3050908@univ-mlv.fr> On 08/21/2011 12:48 PM, saeed yousefi wrote: > Hi > > Yes , I know I can put the text into external resources but it doesn't mean that there shouldn't be such facility in the language itself . > so for what strings exist ? There are lots of places where I want to return a short JSON response from server and I can do it with this feature. > > > regards > > saeed Why not using a lib for that ? http://stackoverflow.com/questions/338586/a-better-java-json-library After all this is one of the great force of Java, you want to do something in Java, there is an app lib for that. R?mi > ________________________________ > From: Tom Ball > To: saeed yousefi > Cc: "coin-dev at openjdk.java.net" > Sent: Sunday, August 21, 2011 4:21 AM > Subject: Re: multiline string/string literal without escape processing > > > There's a great language you should considering using that has built-in support for JS and JSON: JavaScript. Just because something can be written in Java doesn't mean that it necessarily should, as real engineers write code in the language most appropriate for the task before them (IMO). > > > Another option is to put the text you're currently laboriously escaping into external resource files, and just read them in as needed. The advantage to keeping text in different files is that most editors and IDEs provide syntax-specific formatting, which makes it easier to write and mades errors easier to spot. JSON? Use a library to convert your data types instead of doing it by hand, as the overhead is minimal. Write unit tests for those data classes and you have a much more robust solution that scales much better than hand editing. > > Tom > From saeedtej at yahoo.com Sun Aug 21 09:31:05 2011 From: saeedtej at yahoo.com (saeed yousefi) Date: Sun, 21 Aug 2011 09:31:05 -0700 (PDT) Subject: multiline string/string literal without escape processing Message-ID: <1313944265.63012.YahooMailNeo@web111415.mail.gq1.yahoo.com> In fact I have written a JSON/html lib myself like Gson , but writing such lib itself needs this feature . ________________________________ From: R?mi Forax To: coin-dev at openjdk.java.net Sent: Sunday, August 21, 2011 7:15 PM Subject: Re: multiline string/string literal without escape processing On 08/21/2011 12:48 PM, saeed yousefi wrote: > Hi > > Yes , I know I can put the text into external resources but it doesn't mean that there shouldn't be such facility in the language itself . > so for what strings exist ? There are lots of places where I want to return a short JSON response from server and I can do it with this feature. > > > regards > > saeed Why not using a lib for that ? http://stackoverflow.com/questions/338586/a-better-java-json-library After all this is one of the great force of Java, you want to do something in Java, there is an app lib for that. R?mi From per at bothner.com Sun Aug 21 10:03:54 2011 From: per at bothner.com (Per Bothner) Date: Sun, 21 Aug 2011 10:03:54 -0700 Subject: multiline string/string literal without escape processing In-Reply-To: <1313923716.35795.YahooMailNeo@web111406.mail.gq1.yahoo.com> References: <1313867804.56025.YahooMailNeo@web111404.mail.gq1.yahoo.com> <1313923716.35795.YahooMailNeo@web111406.mail.gq1.yahoo.com> Message-ID: <4E513A7A.4070300@bothner.com> IMO more valuable that multiline string/string literal without escape processing would multiline string/string literals with embedded expressions. For example, to pick some arbitrary syntax: #"The percentage is \{a * 100.0 / b}%."# This lends itself to template processing, easier-to-use internationalization, less error-prone println calls, and more. A pure literal multi-line string without embedded expressions seems to be much less useful. Yes, it would be nice to avoid backslash-explosion, but that's mostly a factor in regexps and Windows filenames, which are unlikely to need to be multi-line. -- --Per Bothner per at bothner.com http://per.bothner.com/ From pbenedict at apache.org Sun Aug 21 18:18:27 2011 From: pbenedict at apache.org (Paul Benedict) Date: Sun, 21 Aug 2011 20:18:27 -0500 Subject: multiline string/string literal without escape processing In-Reply-To: <4E513A7A.4070300@bothner.com> References: <1313867804.56025.YahooMailNeo@web111404.mail.gq1.yahoo.com> <1313923716.35795.YahooMailNeo@web111406.mail.gq1.yahoo.com> <4E513A7A.4070300@bothner.com> Message-ID: Long live wrote: > IMO more valuable that multiline string/string literal without escape > processing > would multiline string/string literals with embedded expressions. ?For > example, > to pick some arbitrary syntax: > > ? #"The percentage is \{a * 100.0 / b}%."# > > This lends itself to template processing, easier-to-use > internationalization, > less error-prone println calls, and more. > > A pure literal multi-line string without embedded expressions seems to be > much less useful. ?Yes, it would be nice to avoid backslash-explosion, > but that's mostly a factor in regexps and Windows filenames, which are > unlikely to need to be multi-line. > -- > ? ? ? ?--Per Bothner > per at bothner.com ? http://per.bothner.com/ > > From frederic.martini at gmail.com Mon Aug 22 01:43:27 2011 From: frederic.martini at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Martini?=) Date: Mon, 22 Aug 2011 10:43:27 +0200 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: References: <4E4D3B9E.3040308@oracle.com> Message-ID: On my proposal, parameter's names are stored on a annotation. But a class-file update would be better, even if it's "against the spirit of coin". 2011/8/18 Brian Goetz : > > But, even if it did, another thing that makes a proposal "big" is "touching > method overload resolution rules". And the essence of this proposal is > adding another layer of complexity to method overload resolution. > > I think it does not affects method overload rules. Like Java 5.0 varargs, this proposal is based on a special type that will contains the parameters list. For exemple, a methode like this : public void exemple({int foo=30, String bar="hi"}) will generate a method signature like this : public void exemple(OptArgs) Adding optional parameters will not affect the method signature. From frederic.martini at gmail.com Mon Aug 22 03:18:31 2011 From: frederic.martini at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Martini?=) Date: Mon, 22 Aug 2011 12:18:31 +0200 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: <4E4D3B9E.3040308@oracle.com> References: <4E4D3B9E.3040308@oracle.com> Message-ID: This proposal can also be based on the "Collection Literals", coin-dev at openjdk.java.net : http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001193.html So, an "Named & Optional" bloc can be compiled as a Map. (Of course it would be preferable to use a more specific type instead of Map, in order to avoid possible conflicts) So, this code : public void method({int foo, String bar="Hello"}) { ... } Would be compiled to something like this : public void method(Map $args$) { int foo = UtilityClass.retrieve($args$, "foo", int.class); String bar = UtilityClass.retrieve($args$, "bar", String.class, "Hello"); ... } Like Java 5.0 varargs, the compiler will generate a method with a specific type, so there should be no impact on the method overload resolution rules. The only ambiguity is about overload. The method call "method()" can match the following three methods : public void method(); public void method(Object...); public void method({int optionalArgs=0}); Actually, between the first two, compiler will choose the first one. We can use the same rules : compiler will opt standard method, varargs method or "named&optional" method, in this order. From fyaoxy at gmail.com Mon Aug 22 03:19:16 2011 From: fyaoxy at gmail.com (=?UTF-8?B?5ZCR6ZuF?=) Date: Mon, 22 Aug 2011 18:19:16 +0800 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: References: <4E4D3B9E.3040308@oracle.com> Message-ID: Why so many parameters? It's design problem. 2011/8/22 Fr?d?ric Martini : > On my proposal, parameter's names are stored on a annotation. > But a class-file update would be better, even if it's "against the > spirit of coin". > > > 2011/8/18 Brian Goetz : >> >> But, even if it did, another thing that makes a proposal "big" is "touching >> method overload resolution rules". ?And the essence of this proposal is >> adding another layer of complexity to method overload resolution. >> >> > I think it does not affects method overload rules. > Like Java 5.0 varargs, this proposal is based on a special type that > will contains the parameters list. > > > > For exemple, a methode like this : > > ? ? public void exemple({int foo=30, String bar="hi"}) > > will generate a method signature like this : > > ? ? public void exemple(OptArgs) > > > > Adding optional parameters will not affect the method signature. > > From frederic.martini at gmail.com Mon Aug 22 04:02:07 2011 From: frederic.martini at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Martini?=) Date: Mon, 22 Aug 2011 13:02:07 +0200 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: References: <4E4D3B9E.3040308@oracle.com> Message-ID: I do not think it's a design problem. It's a design problem because the Java language do no provide any clean solution for that. * Overload's method with different parameters count is very painful to write, and confusing to use. * The "Builder pattern" is also painful to write and to use, and the documentation is separed from the method. Some example with this proposal : The 6 ResourceBundle.getBundle() can be replaced by a single method : public static ResourceBundle getBundle(String baseName, {Locale targetLocale=Locale.getDefault(), ClassLoader loader=getLoader(), Control control=Control.INSTANCE); The ProcessBuilder's class can be replaced by a single method : public static Process exec(String[] command, { File directory = new File(""), Map env = null, boolean inheritEnv = true, Redirect stdin = Redirect.PIPE, Redirect stdout = Redirect.PIPE, Redirect stderr = Redirect.PIPE, boolean redirectError = false })); Note : of course method/class will not be replaced for compatibility. It's just an example of possibility for new API... Another example : the Java 7 API java.nio.file use interface OpenOption as varargs to allow us to use specific "flag". try { OutputStream out = Files.newOutputStream(path, StandardOpenOption.SYNC, StandardOpenOption.APPEND)) { ... } Using "named & optional args" may be more readable, with best EDI support, and the possibility to use parameters values (and not only a flag) : try { OutputStream out = Files.newOutputStream(path, sync:true, append:true)) { ... } If the "Collection Literals" is integrated into Java 8, it will be possible to use it to simulate named & optional args using a Map : // method : public static void method(Map map) { int foo = map.containsKey("foo") ? (Integer)map.get("foo") : 10; String bar = map.containsKey("bar") ? (String)map.get("bar") : "Hi"; ... } // actually : Map args = new HashMap(); args.put("foo", 30); args.put("bar", "Hello World !"); method(args); // With "Collection Literals" in Java 8 method({"foo":30, "bar":"Hello World!"); But : - We lost all compiler support (type-check, name-check) - There no possibility for EDI support (autocompletion, etc.) - We must manually retrieve each parameter's value. Le 22 ao?t 2011 12:19, ?? a ?crit : > Why so many parameters? > It's design problem. > > > 2011/8/22 Fr?d?ric Martini : >> On my proposal, parameter's names are stored on a annotation. >> But a class-file update would be better, even if it's "against the >> spirit of coin". >> >> >> 2011/8/18 Brian Goetz : >>> >>> But, even if it did, another thing that makes a proposal "big" is "touching >>> method overload resolution rules". ?And the essence of this proposal is >>> adding another layer of complexity to method overload resolution. >>> >>> >> I think it does not affects method overload rules. >> Like Java 5.0 varargs, this proposal is based on a special type that >> will contains the parameters list. >> >> >> >> For exemple, a methode like this : >> >> ? ? public void exemple({int foo=30, String bar="hi"}) >> >> will generate a method signature like this : >> >> ? ? public void exemple(OptArgs) >> >> >> >> Adding optional parameters will not affect the method signature. >> >> > From fweimer at bfk.de Mon Aug 22 04:33:42 2011 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 22 Aug 2011 11:33:42 +0000 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: (=?iso-8859-1?Q?=22Fr=E9d=E9ric?= Martini"'s message of "Mon, 22 Aug 2011 13:02:07 +0200") References: <4E4D3B9E.3040308@oracle.com> Message-ID: <821uwdu1d5.fsf@mid.bfk.de> * Fr?d?ric Martini: > * The "Builder pattern" is also painful to write and to use, and the > documentation is separed from the method. Another approach to named parameters would be fixing that. For instance, values of structural record type (named tuples) could be used to emulate named parameters and would be quite useful independently. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From sebastian.sickelmann at gmx.de Fri Aug 26 15:24:32 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 27 Aug 2011 00:24:32 +0200 Subject: Enumeration adapters in SE 8 Message-ID: <4E581D20.3080603@gmx.de> Paul Benedict wrote: >Another solution is for the JDK to add an Enumeration/Iterator adapter >class; then just instantiate it during compiler desugaring. May be this is something for project coin in jdk8? Is there a coin in 8? Is there someone who wants to send in an coin-proposal with me for this? > > >On Wed, Aug 24, 2011 at 3:34 PM, Stephen Colebourne >> wrote: >>/ On 24 August 2011 19:10, Dan Smith> wrote: />>>/ I was pointed to some comments on core-libs about adapting Enumerations to for loops in SE 8. (Sorry for the new>thread -- I wasn't subscribed.) It turns out lambdas + extension methods will make this very easy. />>>/ >/>>/ In the API: />>>/ >/>>/ interface Enumeration extends Iterator { />>>/ boolean hasMoreElements(); />>>/ E nextElement(); />>>/ boolean hasNext() default #hasMoreElements; />>>/ E next() default #nextElement; />>>/ void remove() default { throw new UnsupportedOperationException(); } />>>/ } />>/ >/>/ This seems sensible. />>/ >/>/ Is this made up syntax, or another EG decision? />>/ void remove() default { throw new UnsupportedOperationException(); } />>/ >/>/ Stephen />>