Re:Pattern Matching for Java
by lacampbell on Thursday April 20, 2017 @09:19PM
(#14162359)
My point was that the dynamic technique in the posted code was written in a very small, contained point where it would be impossible due to the signature of the surrounding argument for it to go wrong.
void React(Animal me, Animal other)
{
ReactSpecialization(me as dynamic, other as dynamic);
}
Unless you pass in a casted value here, it's fool proof.The point is that if you forget to write one of the ReactSpecialization methods nothing detects it. Perhaps more importantly, if you add a new type of Animal there's nothing to tell you you need to write a bunch of new ReactSpecializations.
Re:Pattern Matching for Java
by lacampbell on Thursday April 20, 2017 @10:44PM
(#14162729)
Aha! There's the crux of an argument. It's a valid point actually, that ties into the expression problem.
As an OO apologist I do feel compelled to point out that
type Animal = Cat | Dog | Mouse
let react = function (a, b)
| Cat, Dog -> ...
...
| x, y -> $"{x} is not interested in {y}."
Would suffer from the exact same issue though.Only if you deliberately add the catch-all case. If you don't and just handle all the cases explicitly, many languages will give you a warning or error when you add a new unhandled variant.
Re:Pattern Matching for Java
by lacampbell on Friday April 21, 2017 @12:54AM
(#14163177)
Yeah, it's a valid point.
None if the function is written correctly, but by that logic you don't need type safety at all. The point is that the dynamic technique gives you no warning if you forget to implement one of the cases.