4 ms·

Exactly. That's what I said in the end of my answer but this is no benefit since instanceof ColoredPointer(x, color) is even shorter and it's really not hard

Exactly. That's what I said in the end of my answer but this is no benefit since instanceof ColoredPointer(x, color) is even shorter and it's really not hard to come up with a variable name. In this case some tools might mark x as unused but that's just nonsense. The catch example is interesting but how often do you completely ignore the exception and should you ever do that? Is that behavior the language should encourage? I feel that this is a solution to a very minor inconvenience that is pretty redundant.

kaba0 4y ago
Okay, what about `instanceof ColoredPoint(3DPoint(_, _, _), var color)`? ColoredPoint’s first field now takes some subtype, and you try to handle only the case where it is a 3DPoint. Now you have to explicitly mention that in the pattern, but it’s possibly long and recursive inner patterns have to be named again. It can quickly get out of hand, so _ is a pretty well-known and widely used approach here in ML-like languages, and its usage causes no harm at all.
- invalidname 4y ago
  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

Okay, what about `instanceof ColoredPoint(3DPoint(_, _, _), var color)`? ColoredPoint’s first field now takes some subtype, and you try to handle only the case where it is a 3DPoint. Now you have to explicitly mention that in the pattern, but it’s possibly long and recursive inner patterns have to be named again. It can quickly get out of hand, so _ is a pretty well-known and widely used approach here in ML-like languages, and its usage causes no harm at all.

invalidname 4y ago
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.