Hacker News Reader

Comment by zwieback | Hacker News Reader

Is type-sensitive code totally acceptable now? I do use it at times but generally try to avoid it.

It should be avoided, but there are legitimate use-cases. Deserialization, for example, might yield a few different types. Especially if you don't control the endpoint and the data back is a mess.

When it is used, it's very nice to have help from the language. I much prefer that to some kind of purist, "they shouldn't do that so we won't help". I certainly miss having type guards when I work in Java.

As long as you use virtual dispatch, an indirected jump table, or some form of run-time tagging, you are writing type-sensitive code whether you have dedicated syntax and types for it or not.

"Type-sensitive" code is encouraged when using the functional style, where you treat objects as dumb "bags of data" that have no inherent functionality of their own. It's still discouraged when following an object-oriented "smart objects" pattern.

How is that particularly functional? In Haskell the same example would be approached at type-level using type classes, something extremely similar to using Interfaces.

I guess in a dynamic functional language you'd probably avoid doing this type of contact-oriented stuff, but you'd rather pass a callback at the last point rather than check type of what you got passed.

I worked in Scala for a while and it was pretty common to use these kind of pattern-match statements for a kind of dispatch mechanism. Not even necessarily with types, it might be something like "do one thing when field a is null and field b is not, another thing when it's the other way around, another thing when they're both null, and still another when neither is." The nice thing about it is the compiler can assert that your match is exhaustive.

> do one thing when field a is null and field b is not

And that would have been a good example! contrary to the one in the docs.

Pattern matching for checking fields of things of the same type is a good use. Pattern matching when checking your parameters type? bad.

> The nice thing about it is the compiler can assert that your match is exhaustive

If you pass a new Shape object for which you forgot to implement a new case in the pattern matcher, you just get the default case, which is wrong, but the compiler can't know that. Now have the function argument ask for something that implements IArea interface and if you don't implement getArea() in your new Shape class, the compiler will know.

Well I think it is pretty common to have a combination of these. You're right that if you configure a default matcher the compiler can no longer tell if the match is as exhaustive as you intended, but I think you can often just avoid that altogether.

I think it's used as an equivalent to discriminated unions, which are generally loved in languages which have them.

I'd say this is probably a bad example of usage for the feature. I use pattern matching in a few places in my own code-base, and it's almost always on interfaces that have a large set of extension methods applied. It's kind of like an entity-component architecture, except the components are added at compile-time, rather than run-time.

Unfortunately, real-life use scenarios are verbose and involved and require a lot of background context that detracts from just demonstrating the syntax. This is just demonstrating the syntax. Standard patterns of software design still apply.

I personally hate when official documentation uses badly applied approaches because it will be invariably be quoted as source for some "best practices" argument at some point.

That's clearly a use case for interfaces and type-level programming.

They could have made a better and shorter case with error handling logic.

Oh, I hate the phrase "best practices" in general. Reeks of cargo-culting.

Yes, it's much easier to write and maintain (up to a point) than an object hierarchy and potentially multiple levels of virtual functions because all the logic is in one place and obvious instead of distributed through x number of files. Of course once you get rid of the OO you'll probably be switching on an enum or something instead.

It's less abstract, simpler and potentially much faster, it's only considered bad by people that think writing OO software is the goal and not a tool to use.

C# as standard uses camelCase for internal variables and UpperCamelCase for public variables, properties and methods.

https://docs.microsoft.com/en-us/dotnet/standard/design-guid...

That's not what he meant. It's not the casing of the names, it's the switching on specific types, rather than building interfaces and using generic programming.

Ah, thank you. That's what I get for commenting when tired!

I'd rather use this than the visitor pattern.

Reply on news.ycombinator.com