81–90 of 100 posts
Earlier quoted context omitted.
Discriminated Unions will make working with Result easier as would provide exhaustive checking. DUs are being designed: https://github.com/dotnet/csharplang/issues/113
Fantastic. I note it's indeed being designed since 2017 so it's probably not as easy as I would hope. The design seems to not have progressed beyond discussion at all in 6 years.
As a dev that uses tuples to standardize returns. I welcome the new using feature.
They don't have generic support no ? You create tuple type for every method ?
Seems utterly trivial, MS making changes for the sake of it. (note to pvs-studio: please show text as text when JS is disabled)
Earlier quoted context omitted.
C# has always been pretty good about evolving the language. Java has recently left the freezer and seems to be catching up as well. I don't use Java but I see people excited about new releases since v11 or so.
C# designers have always made good choices about syntactic additions. Contrast this to modern C++ designers who jam in every new addition with the goal of total inscrutability.
Earlier quoted context omitted.
Source code generators are used because the language itself is not expressive enough. Maybe fix that instead.
That's not really true. Source generation is used at some level to implement expressivity at minimal runtime cost. It's just operating at a different level of abstraction to make different tradeoffs. Whether you do Foo.Serialize() and it uses reflection to enumerate the properties, carries around tags permanently or it uses some compiletime generated function has nothing much to do with expressiveness. If you design…
Likewise the new interceptors infrastructure is a workaround to avoid implementing proper AOP support, like Microsoft Fakes.
I love that Java and C# (not sure about VB.NET and F# in the .NET ecosystem) are continuing to get handy language features instead of collecting dust. The array syntax stuff is a nice win. Having other languages be the guinea pigs for language features is a good way to go.
C# has always been pretty good about evolving the language. Java has recently left the freezer and seems to be catching up as well. I don't use Java but I see people excited about new releases since v11 or so.
As for Java, I guess it would be more notable that they haven't moved as much if it weren't for Kotlin.
The inline array feature is good, but the implementation is very bad. Why would we need to make a struct with an attribute and a weird member?
The inline array feature is good, but the implementation is very bad. Why would we need to make a struct with an attribute and a weird member?
It’s an extraordinary feature that is only intended for optimization of edge cases. Making the feature verbose and somewhat ugly to use seems like an intentional choice. This way if a beginner comes across this “confusing/weird looking” code they can look up the attribute and see what it does, whereas a more convenient/native syntax would be less recognizable and noticeable. This is similar to the idea that you shoul…
Earlier quoted context omitted.
> how can you refactor when any change to any method breaks a test You fix until tests pass. How do you know you adjusted all tests when code changes and tests stay green?
The real problem is you are testing the class behaves like the class, but not the business-driven requirements. Therefore refactoring becomes fearful since detecting bugs is no longer the job of tests.
Earlier quoted context omitted.
The real problem is you are testing the class behaves like the class, but not the business-driven requirements. Therefore refactoring becomes fearful since detecting bugs is no longer the job of tests.
A business model can be described in code as an integration test. Wouldn’t an integration test work in that case?
A business case can be described in code as a test. Period.
A small unit of business functionality can be described in code as test that tests that "unit". A unit test, if you will.
I don't think that the way that you're dividing out "integration tests" is a useful one.
> Wouldn’t an integration test work in that case?
Wouldn’t a test work in that case? Well, yes.