Does anyone know what the dollar syntax is? Similarly, the new dictionary initialiser syntax? Fisnlly, what is private protected?
Edit: these are from https://roslyn.codeplex.com/wikipage?title=Language%20Featur...
C# Dictionary initialization is currently something like this:
var d = new Dictionary<string, string>
{
{ "key", "value" },
{ "but this one", "has spaces" }
}
var d = new Dictionary<string, string>
{
$key = "value",
["but this one"] = "has spaces"
}
The access modifier "private protected" appears to mean "only derived types that are also in the same assembly."
I don't understand the advantage of the dollar syntax though. One character shorter, and makes it look more object-y, obscuring the perf difference.
At least in python, I would love to have syntax like that. (I would use :: instead of .$, but maybe :: is already used in C#.)
Maybe it's just because I work with JSON a fair amount, but I frequently have an it-might-as-well-be-an-object that happens to be stored in a dict. And in theory, this means I need to do foo['bar']['baz'], which is hard to read and unpleasant to type. In practice, I often use a class which overloads attributes as being dict keys, so I can use foo.bar.baz, but this has its own problems. foo::bar::baz would be great.
I, as the next programmer, would hate you if you started trying to use C# as a dynamic language by abusing dictionaries, you're losing all the advantages of C# while still suffering the disadvantages.
(And this ignores converting to JSON. The library I use is designed to be passed dicts. You can teach it to accept arbitrary objects, but that's kind of a hack.)
It replaces a 'magic string' with a 'magic variable name', which is worse than the normal solution for magic strings, which is to move them to a constant.
If I have code in one place that says:
dict["key"] = "value";
var value = dict["key"];
const string KEY = "key"
With the new syntax, I can now write
dict.$key = "value";
var value = dict.$key;
dict.$newkey = "value";
Key symbols aren't becoming a new type - I don't get to write
var key = $key;
var big_key = ["key with spaces"];
I guess the new .$ syntax combines with the null-propagating ?. operator, so you could have nested dictionaries and access them with:
dict?.$subdict?.$subsubdict
which looks... horrible. And suffers from the fact that there's no null-propagating equivalent index access operator, ?[], so I can only use this trick on keys that can be written as C# symbols.
I really feel like I'm completely missing what the use cases are for this capability...
var bigKey = $key_with_spaces; public double GreatestExtent {
get {
Symbol directionOfGreatestExtent = $X;
if (this.Y > this.X) directionOfGreatestExtent = $Y;
return this.#directionOfGreatestExtent;
}
}
Clearly this can be written easily enough without symbol support, but you could argue that the intent of the logic is clearer here than it is in some alternative approaches.
But the thing is that the kind of symbol they've given us isn't a syntax where $foo is a literal which means 'a symbol which accesses the member foo on the target', but instead a syntax where $foo means 'a symbol which accesses the indexer on the target which takes a single string as an argument and passes the string "foo" to it' - just like ["foo"] does.
If I have my co-ordinates stored in a dictionary, I don't need this symbol support to be able to write that kind of logic:
public double GreatestExtent {
get {
string directionOfGreatestExtent = "X";
if (this["Y"] > this["X"]) directionOfGreatestExtent = "Y";
return this[directionOfGreatestExtent];
}
}
public double GreatestExtent {
get {
string directionOfGreatestExtent = "X";
if (this.$Y > this.$X) directionOfGreatestExtent = "Y";
return this[directionOfGreatestExtent];
}
}
So far null propagation seems like the most useful feature for cleaning up cluttered code I'm used to dealing with.
Auto-property initializers are nice, but the syntax looks a bit ugly and I don't see them making that big of a difference in readability. I would rather see something that tackles the ugly-but-necessary construct I see the most: lazy-loading getters. Generic memorization of methods and properties would be even more useful. And yet even more useful would be something that could be used for both memoization and transparent caching:
[Cache(For = 1000 /*milliseconds*/)]
public GetSomethingFromDB(){ ... }
The first one is an answer I wrote on SO and the other is a library I wrote a couple of years ago. Both are are different solutions to the caching problem you describe.
private Lazy<string> _someVariable =new Lazy<string>(SomeClass.IOnlyWantToCallYouOnce);
public string SomeVariable {
get { return _someVariable.Value; }
}
So in your example you could create one to detect your attribute and inject custom logic instead. You can unleash the full power of AOP at the compilation level.
In languages that allow for full macros, many of those features can be implemented as library instead, which also creates the problem everyone has their own little DSL.
Anyway looking to the history of computing, all mainstream languages that started simple as a movement against complexity of some sort, ended up becoming more complex release after release.