Hacker News Reader

Comment by cletus | Hacker News Reader

So some immediate thoughts:

1. Why not just call these "structs"? Everyone knows what a struct is. Also making "struct" a reserved keyword is less likely to cause issues than "record";

2. I get that these are trying to be simple but why can't I compose records from other records? I guess I can have a record member of a record?

3. I couldn't see if records can be passed entirely on the stack like primitive values can. This would be huge. I seem to recall there was some effort to add this to Java but I'm not sure whatever happened to that. It probably added a ton of complexity.

View on HN

1. Records are reference types (heap allocated), structs are not. C# have structs and will also be getting records with 9.0

2. Yes, you can make records of other records.

3. Not yet, but Project Valhalla will be bringing inline types to Java https://wiki.openjdk.java.net/display/valhalla/Main

What do you mean, "structs are not"? As far as I can tell, structs do not exist in Java?

Structs in other similar languages, for example, C#

Mark Valhalla project has been in the minds of people caring about performance for about 16years now...

Struct was a suggested name.

What they mean is that `struct` in GC'd heap oriented languages is generally considered an alias for "a value type", that's what it is in C# or Swift.

Records are shortcut syntax (and some runtime improvements) for a specific category of simple classes but they remain a heap-allocated reference type so calling records "struct" would be extremely misleading and would preclude (and / or make even weirder) the eventual inclusion of user-defined value types.

C# records:

https://github.com/dotnet/roslyn/blob/features/records/docs/...

It's a struct or class but you only define the data members and the compiler auto-generates boiler plate like constructors, equality tests, etc.

So same as Kotlin Data Class? Records is a weird name, IMO.

"Record" is what it was called in Algol and Pascal days.

it's also what's still called by the functional crowd, I believe.

They are called records in F# which predates kotlin

Personally I have been wanting to use headerless objects for a long time (pre java7). The best available option is DirectBuffer, still.

Aren't classes already allocated on the heap? Why would C# need another type like that?

There low overhead data classes. It's takes a lot create a data class correctly. Including implementing equals, hash etc. Plus a good syntax for creating records.

And encourages immutability.

The point of both the C# feature and the Java feature is to reduce boilerplate. They are not for improving the performance of apps.

The comment is wrong. Records are syntactical sugar for either value or reference types (depending on the language). They simply automatically implement equality, constructors and so forth.

1. C popularized the `struct` keyword, but "record" is a more general, language-agnostic term for nominal tuple types in the literature.

2. Yes, it is widely accepted that a has-a relationship is the proper way to compose data. Using inheritance for composition is bad practice.

3. The article mentions inline classes, which is what the proposed value type feature is called these days. Presumably many or most record types will be inline if and when they're both implemented in some future Java version.

It's not structs in C, it's more like records in Haskell.

If you have two records {a: 1, b: 2}, those are equal because they are the same.

If you have two structs {a: 1, b: 2}, those are also equal but they are separate instances that consume more space. The comparison is recursive.

It's more like how string works in Java and most modern languages with constant pools - behaves like values but only takes constant space.

There's a detailed Brian Goetz writeup about much of this at:

https://cr.openjdk.java.net/~briangoetz/amber/datum.html

Disclaimer: it's been a long time since I coded in Java, and I have no knowledge of this new record feature, but coming from clojure I would guess the answers to be:

1. You can't change a record after the fact because if you do it's no longer reliable, it's been tampered with :)

2. Yes, existing records only. You can always create a new record pointing to the old or any other record.

3. Hope not, would make it unpractical to handle verbose facts.

I guess clojure really twisted my mind ;)

Ad 1: Maybe they like pascal, scheme etc. more than c?

"record" is used in the Haskell world, for example. Also ATS.

They are not that similar to a struct in C in that they are not just about being a data carrier. So that might be confusing if that is what you expect.

Future work is intending to solve the third point and add deconstructing the record for pattern matching.

“We can declare a simple x-y point abstraction as follows: record Point(int x, int y) { } which will declare a final class called Point, with immutable components for x and y and appropriate accessors, constructors, equals, hashCode, and toString implementations.”

Reply on news.ycombinator.com