From pbenedict at apache.org Sun May 4 02:07:50 2014 From: pbenedict at apache.org (Paul Benedict) Date: Sat, 3 May 2014 21:07:50 -0500 Subject: State of the Values Message-ID: For anyone interested, here's a new article on perhaps forthcoming value types: http://cr.openjdk.java.net/~jrose/values/values-0.html Cheers, Paul From Ulf.Zibis at CoSoCo.de Sun May 4 16:15:33 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sun, 04 May 2014 18:15:33 +0200 Subject: State of the Values In-Reply-To: References: Message-ID: <536667A5.2040209@CoSoCo.de> I think, this is a great proposal. > Value/primitive convergence. Can we integrate primitives into the values family? > __ByValue class int { ... }? Can we get to a world where primitives are just predefined value types? Does that mean that we could invoke e.g. methods of class Integer on primitive int type? int a = 5; String aAsString = a.toString(); String seven = 7.toString(); That I would like very much! -Ulf Am 04.05.2014 04:07, schrieb Paul Benedict: > For anyone interested, here's a new article on perhaps forthcoming value > types: > > http://cr.openjdk.java.net/~jrose/values/values-0.html > > Cheers, > Paul > > From pbenedict at apache.org Sun May 4 17:27:05 2014 From: pbenedict at apache.org (Paul Benedict) Date: Sun, 4 May 2014 12:27:05 -0500 Subject: State of the Values In-Reply-To: References: Message-ID: These two questions came to mind: 1) If subclassing will be prohibited, will it still be possible to "extend" another value type via delegation? I imagine people will want to delegate to reuse existing value classes. 2) The draft makes mention how most java.lang.Object methods aren't applicable. So does it make sense for value types to extend java.lang.Object? Or, will it take the "enum" route (all extending java.lang.Enum) of forcibly subclassing a new java.lang type and providing "final" behavior for the non-applicable methods? Cheers, Paul From brian.goetz at oracle.com Mon May 5 04:37:29 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 5 May 2014 00:37:29 -0400 Subject: State of the Values In-Reply-To: <536667A5.2040209@CoSoCo.de> References: <536667A5.2040209@CoSoCo.de> Message-ID: <729C0E0E-2D12-4F17-AFDE-CBAA9C34813F@oracle.com> We?ve asked that question ourselves. Its a definite ?maybe?. Answering such questions is a long ways off; our primary focus for the time being is the VM-level semantics; the language semantics come later, and later still ?syntaxy? issues like this. On May 4, 2014, at 12:15 PM, Ulf Zibis wrote: > I think, this is a great proposal. > > > Value/primitive convergence. Can we integrate primitives into the values family? > > __ByValue class int { ... }? Can we get to a world where primitives are just predefined value types? > > Does that mean that we could invoke e.g. methods of class Integer on primitive int type? > int a = 5; > String aAsString = a.toString(); > String seven = 7.toString(); > > That I would like very much! > > -Ulf > > > Am 04.05.2014 04:07, schrieb Paul Benedict: >> For anyone interested, here's a new article on perhaps forthcoming value >> types: >> >> http://cr.openjdk.java.net/~jrose/values/values-0.html >> >> Cheers, >> Paul >> >> > > From r.spilker at gmail.com Mon May 5 14:49:00 2014 From: r.spilker at gmail.com (Roel Spilker) Date: Mon, 5 May 2014 16:49:00 +0200 Subject: State of the Values In-Reply-To: <729C0E0E-2D12-4F17-AFDE-CBAA9C34813F@oracle.com> References: <536667A5.2040209@CoSoCo.de> <729C0E0E-2D12-4F17-AFDE-CBAA9C34813F@oracle.com> Message-ID: Hi all, Good to see this amount of progress already! 1) Is there already a separate mailing list, like for lambdas, for discussing value types? I have some questions/suggestions: 2) In the section "Life without pointers", is states "Null is a valid value of every reference type, meaning ?no instance?. But assignment to, and comparison to, null for value types should be disallowed. This restriction does not apply to the boxed form of a value type." I agree with the idea. But a value can contain references. In some (hopefully rare) cases it's useful to null those. Having a way to "clear" a value would be helpful. Maybe the "empty" value should be part of the generated code: Point.empty(). The developer of the type can provide it, or the user can make his own EMPTY "instance". But since it's necessary for initialization, it might be worth wile investigating if it can become part of the generated code. 3) For evolution purposes, wouldn't it be possible to always use getter methods and allow the field access syntax for accessing the values. That way, public "fields" can later be emulated by providing a getter method. Possibly those methods should marked as getter and not be based on naming patterns. So value class Point { public final int x, y; } would become value class Point { private final int x, y; __Getter public int getX() {return this.x;} __Getter public int getY() {return this.y;} } class Dot { void renderAt(Point p) { drawDot(p.x, p.y) // getter invocation for value types } } 4) By providing (optionally) generated "with"-methods instead of allowing mutable fields and setters, it could be possible to have a lightweight way to modify a single "field" value class Point { public int x, y; public Point withX(int newX) { if (this.x == newX) return this; return new Point(newX, this.y); } } - The users of such a method would understand that they would get a "copy" and not be modifying an existing instance - Escape analysis could often replace this by a single register update p = p.withX(p.x + 1); On Mon, May 5, 2014 at 6:37 AM, Brian Goetz wrote: > We?ve asked that question ourselves. Its a definite ?maybe?. > > Answering such questions is a long ways off; our primary focus for the > time being is the VM-level semantics; the language semantics come later, > and later still ?syntaxy? issues like this. > > On May 4, 2014, at 12:15 PM, Ulf Zibis wrote: > > > I think, this is a great proposal. > > > > > Value/primitive convergence. Can we integrate primitives into the > values family? > > > __ByValue class int { ... }? Can we get to a world where primitives > are just predefined value types? > > > > Does that mean that we could invoke e.g. methods of class Integer on > primitive int type? > > int a = 5; > > String aAsString = a.toString(); > > String seven = 7.toString(); > > > > That I would like very much! > > > > -Ulf > > > > > > Am 04.05.2014 04:07, schrieb Paul Benedict: > >> For anyone interested, here's a new article on perhaps forthcoming value > >> types: > >> > >> http://cr.openjdk.java.net/~jrose/values/values-0.html > >> > >> Cheers, > >> Paul > >> > >> > > > > > > > From sproket at videotron.ca Mon May 5 15:02:53 2014 From: sproket at videotron.ca (Dan Howard) Date: Mon, 05 May 2014 11:02:53 -0400 Subject: State of the Values In-Reply-To: References: Message-ID: <5367A81D.6060403@videotron.ca> I think we have to be careful here. One of the nice features of Java is that generally you can look at piece of code and know what it's doing so I'm not sure going the C# route on value types is really worth it. Consider the following code in C#: class Program { static void Main(string[] args) { Account account = new Account(); account.AcccountNumber = "1234"; account.Name = "Savings"; account.Balance = 10; Console.WriteLine("BEFORE: " + account); adjustAccountBalance(account, 10); Console.WriteLine("AFTER: " + account); Console.ReadLine(); } static void adjustAccountBalance(Account account, float balance) { account.Balance += balance; } } Question: What is the result? In Java the answer is obvious but in C# the correct answer is *unknown*. It all depends on whether Account is a class or struct. It's possible in C# to simply change a class to a struct - everything will compile fine but I've potentially just introduced a mountain of Heisenbugs as developers can easily misinterpret how their "object" will behave when passed to a method. Have we considered just a simple struct like in C? // Lowercase to avoid convention collision with classes. struct account { String accountNumber; String name; float balance; } Wouldn't this solve the issue at hand without introducing unwanted complexity? --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From tom.schindl at bestsolution.at Mon May 5 15:36:24 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 5 May 2014 17:36:24 +0200 Subject: State of the Values In-Reply-To: <5367A81D.6060403@videotron.ca> References: <5367A81D.6060403@videotron.ca> Message-ID: Correct me but this is not working with the proposal as i read it because all field values are final. Tom Von meinem iPhone gesendet > Am 05.05.2014 um 17:02 schrieb Dan Howard : > > I think we have to be careful here. > > One of the nice features of Java is that generally you can look at piece of code and know what it's doing so I'm not sure going the C# route on value types is really worth it. > > Consider the following code in C#: > > class Program > { > static void Main(string[] args) > { > > Account account = new Account(); > account.AcccountNumber = "1234"; > account.Name = "Savings"; > account.Balance = 10; > > Console.WriteLine("BEFORE: " + account); > > adjustAccountBalance(account, 10); > > Console.WriteLine("AFTER: " + account); > > Console.ReadLine(); > } > > static void adjustAccountBalance(Account account, float balance) > { > account.Balance += balance; > } > } > > Question: What is the result? In Java the answer is obvious but in C# the correct answer is *unknown*. It all depends on whether Account is a class or struct. It's possible in C# to simply change a class to a struct - everything will compile fine but I've potentially just introduced a mountain of Heisenbugs as developers can easily misinterpret how their "object" will behave when passed to a method. > > Have we considered just a simple struct like in C? > > // Lowercase to avoid convention collision with classes. > struct account { > String accountNumber; > String name; > float balance; > } > > Wouldn't this solve the issue at hand without introducing unwanted complexity? > > --- > This email is free from viruses and malware because avast! Antivirus protection is active. > http://www.avast.com > > From pbenedict at apache.org Tue May 6 21:29:22 2014 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 6 May 2014 16:29:22 -0500 Subject: State of the Values In-Reply-To: References: Message-ID: I may have answered my own questions after a second reading of the spec. If anyone thinks these answers need tweaking, please let me know. 1) To keep foreign pointers out of value types, and therefore make sure they are "safe", means to only allow construction parameters that are (1) one of the 8 natives or (2) another value type. The latter essentially is a form of "subclassing" but only by copying the values into the new value and adding more data points. 2) Spec says the "value" type will not extend java.lang.Object but the boxed type will. Now some musings... The proposal allows value types through a special keyword (perhaps) and special construction (perhaps). I am not fond of this at all and makes me think of the C schism of struct vs. classes and their separate coding styles. Rather, I propose we look at value types as Java classes that implement a special "no identity" interface contract and let the JVM transform them natively into true value types. In other words, the programmer should write the boxed version, which meets whatever restricted guidelines set forth, and then the JVM can perform its optimizations invisibly. I think Brian Goetz was going down the right path with his (emulated) "value based class" contract in his lambda support. I'd like to see that path continue using today's language constructs rather than dual syntax/coding styles. Paul Cheers, Paul On Sun, May 4, 2014 at 12:27 PM, Paul Benedict wrote: > These two questions came to mind: > 1) If subclassing will be prohibited, will it still be possible to > "extend" another value type via delegation? I imagine people will want to > delegate to reuse existing value classes. > > 2) The draft makes mention how most java.lang.Object methods aren't > applicable. So does it make sense for value types to extend > java.lang.Object? Or, will it take the "enum" route (all extending > java.lang.Enum) of forcibly subclassing a new java.lang type and providing > "final" behavior for the non-applicable methods? > > Cheers, > Paul > From brian.goetz at oracle.com Tue May 6 21:48:14 2014 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 06 May 2014 17:48:14 -0400 Subject: State of the Values In-Reply-To: References: <536667A5.2040209@CoSoCo.de> <729C0E0E-2D12-4F17-AFDE-CBAA9C34813F@oracle.com> Message-ID: <5369589E.7010602@oracle.com> > 1) Is there already a separate mailing list, like for lambdas, for > discussing value types? There will be, eventually. Remember, this is a very early design draft, there's not even a JEP yet. All in due time.