3 ms·

I get that it exists elsewhere and saw it in other languages. I think it looks a bit weird and doesn't convey the intention properly. One of the nice things in

I get that it exists elsewhere and saw it in other languages. I think it looks a bit weird and doesn't convey the intention properly. One of the nice things in Java is that we don't automatically copy ideas from other languages but deliberate on them first. Personally, I think the instanceof syntax for Records is terrible and you're showing off exactly why. It breaks encapsulation entirely. What we need to do is fix records so they will have more OOP related principles. instanceof is a patch and switch should be an anti-pattern. If records allowed inheritance we could just add polymorphic APIs to them and then write more elegant code without the instanceof's.

kaba0 4y ago
> One of the nice things in Java is that we don't automatically copy ideas from other languages but deliberate on them first Sure, but I’m sure it was not an automatic copy, but a well thought-out design by the very competent design team. > It breaks encapsulation entirely Records are almost by definition open. They are only the sum[1] of their constituents. They are part of a more data-oriented approach. Of course the “old” OOP concerns may apply, and there is an escape hatch — one can make a class from a record, and with the coming destructors it won’t need any recompilation, every existing pattern match can work, yet its inner workings can be encapsulated. But this is not the primary purpose for them — they are just plain old data. EDIT: though now that I thought a bit about it, hopefully with `withers` we get an alternative syntax for pattern matching on records, like `ColoredPoint { point: 3DPoint { x } }`. That way pattern matching won’t be tied to the order of the fields. Surely records don’t change often, but still. [1] if we are being pedantic, they are the product of their constituents, they are named product types.

kaba0 4y ago

> One of the nice things in Java is that we don't automatically copy ideas from other languages but deliberate on them first Sure, but I’m sure it was not an automatic copy, but a well thought-out design by the very competent design team. > It breaks encapsulation entirely Records are almost by definition open. They are only the sum[1] of their constituents. They are part of a more data-oriented approach. Of course the “old” OOP concerns may apply, and there is an escape hatch — one can make a class from a record, and with the coming destructors it won’t need any recompilation, every existing pattern match can work, yet its inner workings can be encapsulated. But this is not the primary purpose for them — they are just plain old data. EDIT: though now that I thought a bit about it, hopefully with `withers` we get an alternative syntax for pattern matching on records, like `ColoredPoint { point: 3DPoint { x } }`. That way pattern matching won’t be tied to the order of the fields. Surely records don’t change often, but still. [1] if we are being pedantic, they are the product of their constituents, they are named product types.