   [.net] Why is there no typedef in C#?
  See the following code:Graph<NodeDataType, EdgeDataType>.Node startNode = new Graph<NodeDataType, EdgeDataType>.Node();Graph<NodeDataType, EdgeDataType>.Node endNode = new Graph<NodeDataType, EdgeDataType>.Node();Graph<NodeDataType, EdgeDataType>.Edge edge = new Graph<NodeDataType, EdgeDataType>.Edge(startNode, endNode);Now tell me that isn't begging a typedef. Where has it gone in C#? If type safety is what worried C#'s creators, why couldn't they have created a type-safety-enforcing alternative? And if it's clarity of code that's the problem, how on earth is the above more clear thantypedef Graph<NodeDataType, EdgeDataType>.Node GraphNode;typedef Graph<NodeDataType, EdgeDataType>.Edge GraphEdge;GraphNode startNode = new GraphNode();GraphNode endNode = new GraphNode();GraphEdge edge = new GraphEdge(startNode, endNode);?   
  You can also use:var startNode = new Graph<NodeDataType, EdgeDataType>.Node();var endNode = new Graph<NodeDataType, EdgeDataType>.Node();var edge = new Graph<NodeDataType, EdgeDataType>.Edge(startNode, endNode);Which is somewhat better. Also, I haven't test this, but I think the following will work:// top of the file:using GraphNode = Graph<NodeDataType, EdgeDataType>.Nodel// later...var startNode = new GraphNode();;  The problem with the using statement is that its need to be at the top of the file is very limiting. For example, if I have a class that makes use of the graph that allows for generic NodeData and EdgeData types for the Graph, I will not be able to place the using statement at the top of a file:// This does not work! NodeDataType and EdgeDataType are not yet defined!using GraphNode = Graph<NodeDataType, EdgeDataType>.Node;class UsesGraph<NodeDataType, EdgeDataType>{...}Do you see the problem here? It seems like such a pointless requirement to force that using statement to be at the top of the file.   ;  Coming from C++ myself, and doing a lot of C# development lately, this is one of the C++'isms I miss -- and using var is really the only thing you can do to make it a little more practical.I wonder if its possibly because the language or CLR can't introduce a new type symbol without duplicating all the stuff that make types work in the runtime...Other things I miss are free functions (especially when writing extension methods... why do I have to create a new class just to hold methods which extend an entirely different class?) and locally-scoped, static variables -- which, for some reason, VB.net has, but C# refuses to impliment.Overall, I think a lot of C# design decisions have come down to how the designers think programmers should code, and so we programmers are sort of forced into their world-view. Every language must do this to some extent, but it seems to be a more heavy-handed effort with C#. In many cases they seem to have opted for transparency above conciseness -- one case in point being typedefs, and another case in point being that you must specify in/out/ref not only in the function definition, but at each call site as well. Coming from the C/C++ mindset of "the programmer is god" C# sometimes feels as though its getting in the way of what I want to do, but only occasionally, and in generall all the other neat stuff it brings to the table makes up for these minor annoyances.   ;Quote:Original post by RavyneComing from C++ myself, and doing a lot of C# development lately, this is one of the C++'isms I miss -- and using var is really the only thing you can do to make it a little more practical.I wonder if its possibly because the language or CLR can't introduce a new type symbol without duplicating all the stuff that make types work in the runtime...What would stop the compiler from generating a simple alias? There are already language elements in C# that aren't explicitly supported in the runtime (var for instance).Quote:Original post by RavyneOther things I miss are free functions (especially when writing extension methods... why do I have to create a new class just to hold methods which extend an entirely different class?) and locally-scoped, static variables -- which, for some reason, VB.net has, but C# refuses to impliment.Yeah, I'd like free functions too. I'd also like property scoped fields, alaclass Blah{   public string Name   {  private string _name;  get { return _name; }  set { _name = value; }   }   void Method()   {  _name = "dave"; // ERROR!!   }};  One feature I do wish we had in C# that Java has is anonymous inner classes.interface MyInterface {    int doSomething(int x);}...void foo(MyInterface thing) {    thing.doSomething(0);}void bar() {    // Anonymous inner classes enable you to subclass or implement without    // having to create a named class. Very convenient.   foo(new MyInterface() {   void doSomething(int x) {   return x + 1;    }    });};  I believe that they did not include typedef as the creators of c# thinks that it will obfuscate the code. They didn't like the chain of typedefs which can occurin c++, as it can take some typedef tracing to find out the actual type of a type.sort of like.namespace mycode {   typedef Size std::size_t;   template<class T>   class Vector {   public: typedef Size mycode::Size; // ...   };   class String {   public: typedef Size Vector<wchar_t>::Size; // ...   };}Where you need to first look at mycode::String::Size and then mycode::Vector::Size and then mycode::Size and finally (hopefully) std::size_t for finding out exactly what sizes are supported by mycode::String.It also explains why it is not allowed to chain using statements.Unfortunately I do not remember where I read this.;Quote:Original post by ChaosEngineQuote:Original post by RavyneComing from C++ myself, and doing a lot of C# development lately, this is one of the C++'isms I miss -- and using var is really the only thing you can do to make it a little more practical.I wonder if its possibly because the language or CLR can't introduce a new type symbol without duplicating all the stuff that make types work in the runtime...What would stop the compiler from generating a simple alias? There are already language elements in C# that aren't explicitly supported in the runtime (var for instance).I haven't the faintest idea why they can't/don't personally I beleive that typedefs are far less obtuse than non-typedefs -- sure its perhaps less transparent, but once you've got one template nested in another, or more than about 3-4 template parameters, I think the "advantages" of the supposed transparancy begin to really loose out against the succinctness of a typedef. Quote:Quote:Original post by RavyneOther things I miss are free functions (especially when writing extension methods... why do I have to create a new class just to hold methods which extend an entirely different class?) and locally-scoped, static variables -- which, for some reason, VB.net has, but C# refuses to impliment.Yeah, I'd like free functions too. I'd also like property scoped fields, alaclass Blah{   public string Name   {  private string _name;  get { return _name; }  set { _name = value; }   }   void Method()   {  _name = "dave"; // ERROR!!   }}Oh god yes! That's another one of my pet peeves. I very often use a pattern which defers initialization of a property (which is usually initialized by parsing an XML file or some other expensive process) and I have to make a private class-level variable every time. I've dreamed many times of property scoped fields.I'd have even settled for each property having a single, private, null-initialized "Data" field, although scoped fields would indeed be more flexible.   ;Quote:Original post by mzeo77I believe that they did not include typedef as the creators of c# thinks that it will obfuscate the code. They didn't like the chain of typedefs which can occurin c++, as it can take some typedef tracing to find out the actual type of a type.sort of like.namespace mycode {   typedef Size std::size_t;   template<class T>   class Vector {   public: typedef Size mycode::Size; // ...   };   class String {   public: typedef Size Vector<wchar_t>::Size; // ...   };}Where you need to first look at mycode::String::Size and then mycode::Vector::Size and then mycode::Size and finally (hopefully) std::size_t for finding out exactly what sizes are supported by mycode::String.It also explains why it is not allowed to chain using statements.Unfortunately I do not remember where I read this.Its not your fault of course, but its not difficult to point out how unsound that logic is...If typedefs are chained, then that should express that the outer typedef is intentionally being implimented *in terms of* the inner typedef -- in other words, if the inner typedef changes, then the outer typedef should change as well. Without something like a typedef, if the inner type changes, it also has to be changed all the way up the chain -- furthermore, all that code up the chain will likely be happy to compile, even though it no longer matches the correct type, and I'd be willing to bet that's going to be one of those "WTF" errors the first time someone breaks their code by doing that and gets a mountain of type errors.   ;  There's always this:var factory   = new Graph<NodeDataType, EdgeDataType>();var startNode = factory.CreateNode();var endNode   = factory.CreateNode();var edge = factory.CreateEdge(startNode, endNode);Granted there's probably a less than ideal amount of type info for the programmer there.It may also be worth considering whether different interfaces or useage patterns could be available to help ameliorate this too:var graph = new Graph<NodeDataType, EdgeDataType>();graph.AddEdge(    graph.AddNode(),    graph.AddNode());I don't really know what the C# community feel about the using alias directive. I have a vague recollection of something that gave me the impression it might have been intended to just strip away or 'acronymise' repetitive namespaces, like company or project names. So would it mean then that people prefer, generally, to just inline the type like you're forced to in Java, rather than attempt to alias it at all?I always miss the typedef feature when I switch and start coding in C# but, at the same time, I don't lose any sleep over it either [smile]   