   [.net] Something about C++0x got me thinking about named parameters
  Slashdot has an article, wherein there was discussion about some of Bjourne and company's proposed changes to the standard.  One poster had said something along the lines of wanting named parameters to avoid having to write so many constructors.  Although I think a major shortcoming of C# (I know, only half related to C++) has been lack of _default_ parameters, this was something that slipped under my radar since I had quit using Pascal.  Is there anything immediately preventing someone from writing a constructor like this?:NewClass NC = new NewClass("Type=NewClass;ID=8;");public NewClass (System.String ListOfParameters){  System.Collections.Hashtable Temporary = new System.Collections.HashTable();  System.String[] PairSets = ListOfParameters.Split(";");  foreach (System.String NameValueSet in PairSets)  {    Temporary[NameValueSet.Split("=")[0]] = NameValueSet.Split("=")[1];  }  this.Type = Convert.ToString(Temporary["Type"]);  this.Type = Convert.ToInt32(Temporary["ID"]);  Temporary.Dispose();}
  Your code isn't C++, it's managed C++ as far as I can see (but that doesn't matter in this discussion). There is nothing that prevents you from writing such a constructor. Named parameters are more efficient, are statically checkable and less code to write though.Edit: just noticed that this is the .NET forum, that explains the managed C++ ;)   ;  Obviously, yes you can.  However, you lose all the compile time checks that proper argument lists provide.  Instead, they become runtime errors, and may be completely missed until well after the code's been written.  So you probably shouldn't do so.CM   ;  Heh, yes, it's C#.  Just replace . with :: and it's Managed C++ though.Losing compile time type safety is unfortunate (and something I did overlook, thanks) but I think the time saved not writing 40 different constructors might be worth it for now so long as I check everything and throw the right exceptions as it's processed inside.   ;  I hope you exaggerating. An average fourty constructors for every class seems a bit much. It could depend on the size or type of the project, but I never felt that writing contructors was keeping me from making the dead line.The proposed method looks like it's only going to cause confusion, which is never a good thing when it comes to productivity. Also using a HashTable seems a bit like overkill, but now I'm just nitpicking. ;)To me, still the biggest (but small) shortcoming of C# is lack of decent sprintf/sprintf etc. methods (instead of the format crap it has now). But I digress...   ;  i prefer to wait for c# 3.0 to get that typesave, and till then, write the needed constructors, and for special cases, construct, and set fields with help of accessors afterwards..i don't want string parsing, tokenising, analizing, and type conversions just to construct an object. thats a huge overhead for something simple.   ;Quote:Original post by RKillianHeh, yes, it's C#.  Just replace . with :: and it's Managed C++ though.Losing compile time type safety is unfortunate (and something I did overlook, thanks) but I think the time saved not writing 40 different constructors might be worth it for now so long as I check everything and throw the right exceptions as it's processed inside.That sounds great, but you're still postponing finding a compile time error until run time.  This is icky.  It also forces you into pass-by-value [or, perhaps, pass-by-tostring], which is quite contrary to what one would expect in C#.  In the mean time, you may look into the named constructor and the named parameter idioms.  That site is intended for C++, but I'm sure something similar can be assembled for C#.CM   ;Quote:Original post by WanMasterI hope you exaggerating. An average fourty constructors for every class seems a bit much. It could depend on the size or type of the project, but I never felt that writing contructors was keeping me from making the dead line.The proposed method looks like it's only going to cause confusion, which is never a good thing when it comes to productivity. Also using a HashTable seems a bit like overkill, but now I'm just nitpicking. ;)I don't know, if you looked at my class heirarchy... :PSeriosuly, at the leaf nodes there might be 20 or so properties.  The closed engine from which I have taken some cues uses a scripting language with such a function to create it's objects.  As I have control over the engine this time, I figured bypassing the middleman was an idea to pursue.  The couple hashtables I use throughout the system are for matching properties up by name (it makes more sense with more properties than the example).  Exaggerrating a little, yeah, still wanted to make the point though.I suppose it's particularly appealing as a shortcut right now because at the earlier stages of a project you have so much stuff that depends on so much other stuff that needs done to even work that it's maddeningly circular.  Not exactly sure what I'll go with now, hopefully I can get a grip before it spirals out of control.  Appreciate the input from everyone though, it's given me some ideas to consider.Quote:Original post by davepermeni prefer to wait for c# 3.0 to get that typesave, and till then, write the needed constructors, and for special cases, construct, and set fields with help of accessors afterwardsOr Microsoft could just stop with these half-completed runtimes.  I hate to bash them because of the implications but I had to wait long enough for 2.0 to fix what was broken or missing in 1.1.  Being locked into a particular version of the framework, as opposed to, say, regular C++ going straight to machine code every time no matter what compiler, is one of the biggest disadvantages of .NET.   