From frederic.martini at gmail.com Thu Sep 1 02:56:15 2011 From: frederic.martini at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Martini?=) Date: Thu, 1 Sep 2011 11:56:15 +0200 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: <821uwdu1d5.fsf@mid.bfk.de> References: <4E4D3B9E.3040308@oracle.com> <821uwdu1d5.fsf@mid.bfk.de> Message-ID: I think that "optional & named parameters" will be very useful, using named tuples, Map or another specific type. For another exemple, look at the NIO.2 File API. It simulate "optional and named parameters" with a "hack" using a marker interface (CopyOption, OpenOption). * There are some enums that implement them (StandardCopyOption, StandardOpenOption, LinkOption), for standard's values * And some more specific implementation can define new value by implementing interfaces (there is no real example to my knowledge) Example : // Metode signature : InputStream newInputStream (Path path, OpenOption... options) OutputStream newOutputStream(Path path, OpenOption... options) // Some usage : InputStream in = Files.newInputStream(path, LinkOption.NOFOLLOW_LINKS); OutputStream out = Files.newOutputStream(path, StandardOpenOption.APPEND, StandardOpenOption.SYNC); // Possible use of a non-standard option (imaginary example) InputStream in = Files.newInputStream(path, AnUtilityClass.bufferSize(8192) ); However, in my opinion, this "pattern" is quite limited, because it is difficult to determine the possible values??, even for the standard values?? (so EDI can not offer a full autocompletion), and lot's of these values depends of the method. With "optional and named parameters", we could provide a better API, specifying the possible values ??in the method signature (IDE can use it for autocompletion) Example : // Metode signature : InputStream newInputStream (Path path, {boolean noFollowLinks = false, ...} namedArgs) OutputStream newOutputStream(Path path, {boolean noFollowLinks = false, boolean append = false, boolean truncate = true, boolean create = true, createNew = false, boolean sync = false, boolean dsync = false, boolean deleteOnClose = false, boolean sparse = false, ...} namedArgs) /* varargs means : compiler accept any others name/key not declared on the function type */ // Some usage : InputStream in = Files.newInputStream(path, noFollowLinks:false); OutputStream out = Files.newOutputStream(path, append:true, sync:true); // Possible use of a non-standard option (imaginary example) InputStream in = Files.newInputStream(path, bufferSize:8192); However, non-standard args via varargs introduce a problem : as any key/value can be used, compiler cannot detect typo error. Exemple : // bad name : 'followLinks' instead of 'noFollowLinks' // but it's was considerer as a non-standard args : InputStream in = Files.newInputStream(path, followLinks:true); // compile OK but might produce a runtime error A solution can be to use a warning/error and an annotation in order to detect problem at compile time : InputStream in = Files.newInputStream(path, followLinks:true); // Compile WARNING/ERROR : 'followLinks' is not a valid named parameters // use @Extended for non-standard args InputStream in = Files.newInputStream(path, bufferSize:8192); // Compile WARNING/ERROR : 'bufferSize' is not a valid named parameters // use @Extended for non-standard args InputStream in = Files.newInputStream(path, @Extended bufferSize:8192); // Compile OK We can also use enum in order to "group" incompatible option (ex: append or truncate), in order to improve method signature : enum OpenMode { APPEND, TRUNCATE } enum CreateMode { CREATE, CREATE_IF_NEW, DO_NO_CREATE } enum SyncMode { NONE, SYNC, DSYNC } OutputStream newOutputStream(Path path, {boolean followLinks:true, OpenMode open = TRUNCATE, CreateMode create = CREATE, SyncMode sync = NONE, boolean deleteOnClose = false, boolean sparse = false, ...} namedArgs) Don't you think that this is clearer than newOutputStream(Path,OptionOption...) ??? 2011/8/22 Florian Weimer > > * 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. > > From fyaoxy at gmail.com Thu Sep 1 05:21:31 2011 From: fyaoxy at gmail.com (=?UTF-8?B?5ZCR6ZuF?=) Date: Thu, 1 Sep 2011 20:21:31 +0800 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: References: <4E4D3B9E.3040308@oracle.com> <821uwdu1d5.fsf@mid.bfk.de> Message-ID: Again, It's problem of design. That example just need some kind of factory or builder to reuse. Don't make error for existed error! My words is simple, and the logic is simple as well. If someone not like USA(not american, not US, just only USA soo), then such as tuple return value or typed vary parameter more helpfull. Cheers, Qinxian From frederic.martini at gmail.com Thu Sep 1 06:17:09 2011 From: frederic.martini at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Martini?=) Date: Thu, 1 Sep 2011 15:17:09 +0200 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: References: <4E4D3B9E.3040308@oracle.com> <821uwdu1d5.fsf@mid.bfk.de> Message-ID: This "error" is present on the new File API from Java 7... I'm agree that a builder can be a better choice. But, IMHO, the builder is not the best solution, it's only the least worst option... It's very painful and boring to write, and it's not easily extendable. Same example with a Builder : enum OpenMode { APPEND, TRUNCATE } enum CreateMode { CREATE, CREATE_IF_NEW, DO_NO_CREATE } enum SyncMode { NONE, SYNC, DSYNC } static class OpenOptions { private boolean followLinks = true; private OpenMode open = OpenMode.TRUNCATE; private CreateMode create = CreateMode.CREATE; private SyncMode syn = SyncMode.NONE; private boolean deleteOnClose = false; private boolean sparse = false; public boolean isFollowLinks() { return followLinks; } public OpenOptions setFollowLinks(boolean followLinks) { this.followLinks = followLinks; return this; } public OpenMode getOpen() { return open; } public OpenOptions setOpen(OpenMode open) { this.open = open; return this; } public CreateMode getCreate() { return create; } public OpenOptions setCreate(CreateMode create) { this.create = create; return this; } public SyncMode getSyn() { return syn; } public OpenOptions setSyn(SyncMode syn) { this.syn = syn; return this; } public boolean isDeleteOnClose() { return deleteOnClose; } public OpenOptions setDeleteOnClose(boolean deleteOnClose) { this.deleteOnClose = deleteOnClose; return this; } public boolean isSparse() { return sparse; } public OpenOptions setSparse(boolean sparse) { this.sparse = sparse; return this; } } OutputStream newOutputStream(Path path, OpenOptions options); Fred, 2011/9/1 ?? : > Again, It's problem of design. > That example just need some kind of factory or builder to reuse. > > Don't make error for existed error! > > My words is simple, and the logic is simple as well. > > If someone not like USA(not american, not US, just only USA soo), then > such as tuple return value or typed vary parameter more helpfull. > > Cheers, > Qinxian > > From pbenedict at apache.org Thu Sep 1 06:53:31 2011 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 1 Sep 2011 08:53:31 -0500 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: References: <4E4D3B9E.3040308@oracle.com> <821uwdu1d5.fsf@mid.bfk.de> Message-ID: Sorry, I meant the named/optional parameters proposal. 2011/9/1 Fr?d?ric Martini : > This "error" is present on the new File API from Java 7... > > > I'm agree that a builder can be a better choice. > But, IMHO, the builder is not the best solution, it's only the least > worst option... > It's very painful and boring to write, and it's not easily extendable. > > > > > > Same example with a Builder : > > > > enum OpenMode { APPEND, TRUNCATE } > enum CreateMode { CREATE, CREATE_IF_NEW, DO_NO_CREATE } > enum SyncMode { NONE, SYNC, DSYNC } > > static class OpenOptions { > ? ? ? ?private boolean followLinks = true; > ? ? ? ?private OpenMode open = OpenMode.TRUNCATE; > ? ? ? ?private CreateMode create = CreateMode.CREATE; > ? ? ? ?private SyncMode syn = SyncMode.NONE; > ? ? ? ?private boolean deleteOnClose = false; > ? ? ? ?private boolean sparse = false; > > ? ? ? ?public boolean isFollowLinks() { > ? ? ? ? ? ? ? ?return followLinks; > ? ? ? ?} > ? ? ? ?public OpenOptions setFollowLinks(boolean followLinks) { > ? ? ? ? ? ? ? ?this.followLinks = followLinks; > ? ? ? ? ? ? ? ?return this; > ? ? ? ?} > ? ? ? ?public OpenMode getOpen() { > ? ? ? ? ? ? ? ?return open; > ? ? ? ?} > ? ? ? ?public OpenOptions setOpen(OpenMode open) { > ? ? ? ? ? ? ? ?this.open = open; > ? ? ? ? ? ? ? ?return this; > ? ? ? ?} > ? ? ? ?public CreateMode getCreate() { > ? ? ? ? ? ? ? ?return create; > ? ? ? ?} > ? ? ? ?public OpenOptions setCreate(CreateMode create) { > ? ? ? ? ? ? ? ?this.create = create; > ? ? ? ? ? ? ? ?return this; > ? ? ? ?} > ? ? ? ?public SyncMode getSyn() { > ? ? ? ? ? ? ? ?return syn; > ? ? ? ?} > ? ? ? ?public OpenOptions setSyn(SyncMode syn) { > ? ? ? ? ? ? ? ?this.syn = syn; > ? ? ? ? ? ? ? ?return this; > ? ? ? ?} > ? ? ? ?public boolean isDeleteOnClose() { > ? ? ? ? ? ? ? ?return deleteOnClose; > ? ? ? ?} > ? ? ? ?public OpenOptions setDeleteOnClose(boolean deleteOnClose) { > ? ? ? ? ? ? ? ?this.deleteOnClose = deleteOnClose; > ? ? ? ? ? ? ? ?return this; > ? ? ? ?} > ? ? ? ?public boolean isSparse() { > ? ? ? ? ? ? ? ?return sparse; > ? ? ? ?} > ? ? ? ?public OpenOptions setSparse(boolean sparse) { > ? ? ? ? ? ? ? ?this.sparse = sparse; > ? ? ? ? ? ? ? ?return this; > ? ? ? ?} > } > > OutputStream newOutputStream(Path path, OpenOptions options); > > > > Fred, > > > 2011/9/1 ?? : >> Again, It's problem of design. >> That example just need some kind of factory or builder to reuse. >> >> Don't make error for existed error! >> >> My words is simple, and the logic is simple as well. >> >> If someone not like USA(not american, not US, just only USA soo), then >> such as tuple return value or typed vary parameter more helpfull. >> >> Cheers, >> Qinxian >> >> > > From frederic.martini at gmail.com Thu Sep 1 07:05:14 2011 From: frederic.martini at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Martini?=) Date: Thu, 1 Sep 2011 16:05:14 +0200 Subject: PROPOSAL: Named and Optional parameters, "Java-style" In-Reply-To: References: <4E4D3B9E.3040308@oracle.com> <821uwdu1d5.fsf@mid.bfk.de> Message-ID: Yes, I think it's might be a good alternative to the systematic use of Builder, for method with multiple parameters. Fred, Le 1 septembre 2011 15:53, Paul Benedict a ?crit : > Sorry, I meant the named/optional parameters proposal. > > 2011/9/1 Fr?d?ric Martini : >> This "error" is present on the new File API from Java 7... >> >> >> I'm agree that a builder can be a better choice. >> But, IMHO, the builder is not the best solution, it's only the least >> worst option... >> It's very painful and boring to write, and it's not easily extendable. >> >> >> >> >> >> Same example with a Builder : >> >> >> >> enum OpenMode { APPEND, TRUNCATE } >> enum CreateMode { CREATE, CREATE_IF_NEW, DO_NO_CREATE } >> enum SyncMode { NONE, SYNC, DSYNC } >> >> static class OpenOptions { >> ? ? ? ?private boolean followLinks = true; >> ? ? ? ?private OpenMode open = OpenMode.TRUNCATE; >> ? ? ? ?private CreateMode create = CreateMode.CREATE; >> ? ? ? ?private SyncMode syn = SyncMode.NONE; >> ? ? ? ?private boolean deleteOnClose = false; >> ? ? ? ?private boolean sparse = false; >> >> ? ? ? ?public boolean isFollowLinks() { >> ? ? ? ? ? ? ? ?return followLinks; >> ? ? ? ?} >> ? ? ? ?public OpenOptions setFollowLinks(boolean followLinks) { >> ? ? ? ? ? ? ? ?this.followLinks = followLinks; >> ? ? ? ? ? ? ? ?return this; >> ? ? ? ?} >> ? ? ? ?public OpenMode getOpen() { >> ? ? ? ? ? ? ? ?return open; >> ? ? ? ?} >> ? ? ? ?public OpenOptions setOpen(OpenMode open) { >> ? ? ? ? ? ? ? ?this.open = open; >> ? ? ? ? ? ? ? ?return this; >> ? ? ? ?} >> ? ? ? ?public CreateMode getCreate() { >> ? ? ? ? ? ? ? ?return create; >> ? ? ? ?} >> ? ? ? ?public OpenOptions setCreate(CreateMode create) { >> ? ? ? ? ? ? ? ?this.create = create; >> ? ? ? ? ? ? ? ?return this; >> ? ? ? ?} >> ? ? ? ?public SyncMode getSyn() { >> ? ? ? ? ? ? ? ?return syn; >> ? ? ? ?} >> ? ? ? ?public OpenOptions setSyn(SyncMode syn) { >> ? ? ? ? ? ? ? ?this.syn = syn; >> ? ? ? ? ? ? ? ?return this; >> ? ? ? ?} >> ? ? ? ?public boolean isDeleteOnClose() { >> ? ? ? ? ? ? ? ?return deleteOnClose; >> ? ? ? ?} >> ? ? ? ?public OpenOptions setDeleteOnClose(boolean deleteOnClose) { >> ? ? ? ? ? ? ? ?this.deleteOnClose = deleteOnClose; >> ? ? ? ? ? ? ? ?return this; >> ? ? ? ?} >> ? ? ? ?public boolean isSparse() { >> ? ? ? ? ? ? ? ?return sparse; >> ? ? ? ?} >> ? ? ? ?public OpenOptions setSparse(boolean sparse) { >> ? ? ? ? ? ? ? ?this.sparse = sparse; >> ? ? ? ? ? ? ? ?return this; >> ? ? ? ?} >> } >> >> OutputStream newOutputStream(Path path, OpenOptions options); >> >> >> >> Fred, >> >> >> 2011/9/1 ?? : >>> Again, It's problem of design. >>> That example just need some kind of factory or builder to reuse. >>> >>> Don't make error for existed error! >>> >>> My words is simple, and the logic is simple as well. >>> >>> If someone not like USA(not american, not US, just only USA soo), then >>> such as tuple return value or typed vary parameter more helpfull. >>> >>> Cheers, >>> Qinxian >>> >>> >> >> > From isidore at setgame.com Wed Sep 14 13:33:52 2011 From: isidore at setgame.com (Llewellyn Falco) Date: Wed, 14 Sep 2011 13:33:52 -0700 Subject: Coin 2 Message-ID: Sorry, been out a bit lately, but I thought I saw an email asking for ideas for the next round of coin. Couldn't find it when searching though, and haven't seen a bunch of suggestions. 1) is the call for coin2 ideas open? 2) is it on this list? -- Llewellyn Falco www.approvaltests.com From joe.darcy at oracle.com Wed Sep 14 17:26:42 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 14 Sep 2011 17:26:42 -0700 Subject: Coin 2 In-Reply-To: References: Message-ID: <4E714642.8010505@oracle.com> Hello Llewellyn. There should be an update on "coin, the flip side" by the end of JavaOne this year. Cheers, -Joe On 9/14/2011 1:33 PM, Llewellyn Falco wrote: > Sorry, been out a bit lately, but I thought I saw an email asking for > ideas for the next round of coin. > Couldn't find it when searching though, and haven't seen a bunch of suggestions. > > 1) is the call for coin2 ideas open? > 2) is it on this list? > > > From sergey.bylokhov at oracle.com Mon Sep 19 19:13:55 2011 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 20 Sep 2011 06:13:55 +0400 Subject: jsr 305 Message-ID: <4E77F6E3.7040300@oracle.com> Hello, all. Does anybody know what happens with jsr305? http://jcp.org/en/jsr/detail?id=305 Probably it is replaced by another jsr? Can it be integrated as part of coin project? Thanks. -- Best regards, Sergey. From benjamin.john.evans at gmail.com Mon Sep 19 23:13:58 2011 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Tue, 20 Sep 2011 07:13:58 +0100 Subject: jsr 305 In-Reply-To: <4E77F6E3.7040300@oracle.com> References: <4E77F6E3.7040300@oracle.com> Message-ID: Hi Sergey, I am not an expert in what happened to JSR 305, but from a quick look at it, it seems to have a big overlap with JSR 308 (Type Annotations), which is still an active JSR. So you may want to approach the Spec Lead / EG for JSR 308 and see what their current status is - the last I heard they were interested in trying to make the cut for JDK 8. Does anyone have more information? Thanks, Ben On Tue, Sep 20, 2011 at 3:13 AM, Sergey Bylokhov wrote: > Hello, all. > > Does anybody know what happens with jsr305? > http://jcp.org/en/jsr/detail?id=305 > > Probably it is replaced by another jsr? Can it be integrated as part of > coin project? > > > Thanks. > > -- > Best regards, Sergey. > > > From joe.darcy at oracle.com Tue Sep 20 12:00:32 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 20 Sep 2011 12:00:32 -0700 Subject: jsr 305 In-Reply-To: References: <4E77F6E3.7040300@oracle.com> Message-ID: <4E78E2D0.4050303@oracle.com> Hello. First, a procedural point, the party responsible for making progress on a JSR is the spec lead, which in the case of JSR 305 is Bill Pugh. When I last spoke to Bill about 18 months ago, he said he felt the annotations needed more use on real-world code before they could be fully standardized. I assume that the JSR has remained in that state since then. JSR 308 is primarily about allowing annotations in more locations in a source file and *not* about defining more annotations. -Joe Ben Evans wrote: > Hi Sergey, > > I am not an expert in what happened to JSR 305, but from a quick look > at it, it seems to have a big overlap with JSR 308 (Type Annotations), > which is still an active JSR. > > So you may want to approach the Spec Lead / EG for JSR 308 and see > what their current status is - the last I heard they were interested > in trying to make the cut for JDK 8. > > Does anyone have more information? > > Thanks, > > Ben > > On Tue, Sep 20, 2011 at 3:13 AM, Sergey Bylokhov > wrote: > >> Hello, all. >> >> Does anybody know what happens with jsr305? >> http://jcp.org/en/jsr/detail?id=305 >> >> Probably it is replaced by another jsr? Can it be integrated as part of >> coin project? >> >> >> Thanks. >> >> -- >> Best regards, Sergey. >> >> >> >> > >