Recommended Posts

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?:

Share this post

Link to post

Share on other sites

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

0

Share this post

Link to post

Share on other sites

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.

0

Share this post

Link to post

Share on other sites

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...

Share this post

Link to post

Share on other sites

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#.

Share this post

Link to post

Share on other sites

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... :P

Seriosuly, 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 afterwards

Or 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.