Pattern Matching for Java

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.

[ Parent | on HN ]

Re:Pattern Matching for Java by lmm on Thursday April 20, 2017 @09:58PM (#14162548)

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

Re:Pattern Matching for Java by lmm on Thursday April 20, 2017 @11:07PM (#14162814)

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.

[ Parent | on HN ]

Re:Pattern Matching for Java by lacampbell on Friday April 21, 2017 @12:54AM (#14163177)

Yeah, it's a valid point.

[ Parent | on HN ]