5 ms·

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

jdmichal 7y ago
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.
AndrewDucker 7y ago
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-guidelines/capitalization-conventions https://docs.microsoft.com/en-us/dotnet/standard/design-guid...
- moron4hire 7y ago
  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.
  - AndrewDucker 7y ago
    Ah, thank you. That's what I get for commenting when tired!
moron4hire 7y ago
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.
- bernawil 7y ago
  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.
  - moron4hire 7y ago
    Oh, I hate the phrase "best practices" in general. Reeks of cargo-culting.
akdor1154 7y ago
I think it's used as an equivalent to discriminated unions, which are generally loved in languages which have them.
seanmcdirmid 7y ago
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.
twblalock 7y ago
I'd rather use this than the visitor pattern.
thurn 7y ago
"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.
- bernawil 7y ago
  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.
  - emodendroket 7y ago
    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.
    - bernawil 7y ago
      > 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.
flukus 7y ago
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.

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.

AndrewDucker 7y ago

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-guidelines/capitalization-conventions https://docs.microsoft.com/en-us/dotnet/standard/design-guid...

moron4hire 7y ago
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.
- AndrewDucker 7y ago
  Ah, thank you. That's what I get for commenting when tired!

moron4hire 7y ago

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.

bernawil 7y ago
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.
- moron4hire 7y ago
  Oh, I hate the phrase "best practices" in general. Reeks of cargo-culting.

akdor1154 7y ago

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

seanmcdirmid 7y ago

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.

twblalock 7y ago

I'd rather use this than the visitor pattern.

thurn 7y ago

"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.

bernawil 7y ago
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.
- emodendroket 7y ago
  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.
  - bernawil 7y ago
    > 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.

flukus 7y ago

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.