3 ms·
> I don't really like this immutable approach, I want setters too. > I don't need those autogenerated equals/etc implementations, it's just code bloat. May be
by _bxg1 7y ago
> I don't really like this immutable approach, I want setters too.
> I don't need those autogenerated equals/etc implementations, it's just code bloat. May be it's OK to introduce some syntax to automatically generate them like `String toString() default;` but it should not be implicit.
It sounds like you just want... regular classes? I don't understand your position here. Immutable data structures have many uses and are quite popular. If that's not what you want, why use these at all?
> Java developers used `getProp()` forever, now it's `prop()`. Shall we rewrite old classes or tools? Shall we live with two different styles in one codebase?
C# is the same way. The getProp() convention isn't as strong because it's had computed properties for longer, but one doesn't have to preclude the other.
- Rebelgecko 7y ago>It sounds like you just want... regular classes? I don't understand your position here. Immutable data structures have many uses and are quite popular. If that's not what you want, why use these at all? Records provide a lot of syntactic sugar that classes don't (which is the whole reason to use them— there's nothing stopping you from creating a regular class with all final fields). edit: I'm assuming that the "finality" of fields in records is identical to the shallow finality of a final field in an object
- dmitriid 7y ago> It sounds like you just want... regular classes I wish Java provided syntax sugar similar to C#'s with {get; set;} and quick initialization with new C { field1 = X, field2 = Y, ... } Java is unnecessarily verbose in this regard. Records bring syntactic sugar to records only. And you're stuck with pages upon pages of unnecessary boilerplate code for classes.