31–37 of 37 posts
I feel like in a few more years and 2-3 major versions C# will have all the useful features of F#. It will also keep being much more exciting because our benevolent corporate visionaries manage to add new gotchas with every major and some minor releases
All of the caveats basically boil down to "if you need to access the private backing field from anywhere other than the property getter/setter; then be aware it's going to have a funky non C# compliant field name". In the EF Core and Automapper type of cases, I consider it an anti-pattern that something outside the class is taking a dependency on a private member of the class in the first place, so the compiler is re…
It's another variation of the "parse don't validate" dance. Just because you can do model validation in property setters doesn't always mean it is the best place to do model validation. If you are trying to bypass the setter in a DB Model, then you may have data in your database that doesn't validate, you just want to "parse" it and move on.
It is similar with auto-mapping scenarios, with the complication that automapping was originally meant to be the Validation step in some workflows and code architectures. I think that's personally why AutoMapper and other similar libraries have had a code smell to me as where those tools are often used are "parsing boundaries" more than they should be "validation boundaries" and the coupling between validation logic and AutoMapper logic to me starts to feel like a big ball of spaghetti to me versus a dedicated validation layer that is only concerned with validation not also doing a lot of heavy lifting in copying data around.
How does C# the language or C# the language standard evolution process accommodate a new keyword with such a generic name? Is it context-dependent?
Historically every time new keywords are added, they try to make them contextual so that existing code won't break. 'await' and 'yield' are both examples where a new keyword was added without (generally) breaking existing code - they're only keywords in specific contexts and the way you use them ensures that existing code won't parse ambiguously, AFAIK.
Part of why C# has been so successful in introducing new contextual keywords is that they've been there all along. I think C# 1.0 was ahead of the game on that, and it's interesting how much contextual keywords have started being a bigger tool in language design since C# (all of ES3 of ES4 and some of ES5 were predicated on keywords are always keywords and ES6/ES2015 is where you first start to the shift in JS to a broader contextual keyword approach which seems equal parts inspired by C# as not).
All of the caveats basically boil down to "if you need to access the private backing field from anywhere other than the property getter/setter; then be aware it's going to have a funky non C# compliant field name". In the EF Core and Automapper type of cases, I consider it an anti-pattern that something outside the class is taking a dependency on a private member of the class in the first place, so the compiler is re…
I'm surprised there isn't something pseudorandom thrown in for good measure – like a few digits of a hash of the source file.
It is the compiler's job to guard encapsulation boundaries in most situations, but it's also not necessarily the compiler's job to guard encapsulation boundaries in all situations. There are a lot of good reasons code may want to marshall/serialize raw data. There are a lot of good reasons where cross-cutting is desirous (logging, debugging, meta-programming), which is a part of why .NET has such rich runtime reflection tools.
All of the caveats basically boil down to "if you need to access the private backing field from anywhere other than the property getter/setter; then be aware it's going to have a funky non C# compliant field name". In the EF Core and Automapper type of cases, I consider it an anti-pattern that something outside the class is taking a dependency on a private member of the class in the first place, so the compiler is re…
That's longstanding behaviour. Ever since features such as anonymous types or lambdas arrived, they mean that classes and methods need to be generated from them. And of course these need names, assigned by the compiler. But these names are deliberately not allowed from the code. The compiler allows itself a wider set of names, including the "" chars.
I have heard them referred to as "unspeakable names" because it's not that they're unknown, you literally can't say them in the code.
e.g. by Jon Skeet, here https://codeblog.jonskeet.uk/category/async/ from 2013.
> they’re all "unspeakable" names including angle-brackets, just like all compiler-generated names.
I always shy away from syntax sugars. If I like a private field with setter and getter I write it into my code. The most of the code is written by autocomplete and if I do now like to se it I just fold it away. I have control over the naming and I can set breakpoints into the getter/setter to trap all those case where I somehow write rubbish. I also have the benefit of seeing the field in my debugger and can access t…
> I can set breakpoints into the getter/setter field doesn't stop this. > I also have the benefit of seeing the field in my debugger The debugger could still show it. The backing field is still there.
Earlier quoted context omitted.
> I can set breakpoints into the getter/setter field doesn't stop this. > I also have the benefit of seeing the field in my debugger The debugger could still show it. The backing field is still there.
the text says the backing variable is hidden from debugger by attribut, isn't it?