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.
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.
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.
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.
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.
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.”
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.