No static in C# interfaces

[peewee_RotA]

It's probably telling that I've never run into this problem until now, but I'm really ticked off about it.

C# interfaces can't be implemented as static, and cannot require a member to be static. The excuse is that interfaces should describe behavior, not implementation detail. Ok, that's fine, but by not allowing me to implement a behavior as static YOU ARE FORCING ME TO FOLLOW AN IMPLEMENTATION DETAIL.

 

[QwazyWabbit]

You were already doomed to that when you selected C#. It's called customer lock-in. The same thing applies when you select Objective-C on Apple platforms.

[kren.Z]

I went over interfaces and OOP in Java but never really understood it, let alone actually implement any of it. Now that I'm starting to write bigger programs I have to find ways to break up my code (for my own sake) and find myself saying "Hey, this approach would be useful!".  I'm not yet that good of a programmer to have gripes about a specific language lol.

What's great about C# (from your standpoint)? I hear a lot of good things about it...

[kren.Z]

Wondering what you guys prefer/recommend/use for Source Control. Right now I'm thinking mercurial [http://mercurial.selenic.com/] and Git/Git Hub.

I need something with great merge capabilities. e.g. 2 people working on different parts of the same file.

[peewee_RotA]

What's great about C# (from your standpoint)? I hear a lot of good things about it...

C# is VB with semi-colons. I hated it for a long time, but was pretty much forced to move to it. MS platform web applications all but require it. The only thing I like about it is WPF. I am kind of happy that it's a managed language because having reliable GC is great for desktop apps.

When it comes to real heavy lifting, C# is not the best idea. There is overhead associated with it and I hear that the crap thrown in from the CLR to perform reflection really bloats the app. That and when it comes to memory intensive stuff, like large image processing, the managed parts get in the way like an elephant in your driveway.

So to answer your question directly...

What is great about C#? There are lots of good paying jobs that require it. 

[peewee_RotA]

You were already doomed to that when you selected C#. It's called customer lock-in. The same thing applies when you select Objective-C on Apple platforms.

QFT

Wondering what you guys prefer/recommend/use for Source Control. Right now I'm thinking mercurial [http://mercurial.selenic.com/] and Git/Git Hub.

I need something with great merge capabilities. e.g. 2 people working on different parts of the same file.

I recommend Subversion because it has the easiest interface and smallest learning curve. Right now I use yesterday's garbage known as Starteam.

Git is popular, but I've had nothing but bad experiences with it. When interacting with a coworker who was proficient with its command line, everything we tried to do took about 5 times longer than we expected, so we stopped and switched everything to SVN.

I hear CVS is a great option. (but I've been shopping at Walgreens lately)

[QwazyWabbit]

SVN is the most mature. Subversion is supplanting it but it's essentially SVN. Git is the newest, IIRC and Xcode 4 on the Apple platform automatically creates a git repository for projects when you create them so it's a no-brainer there. Xcode also interfaces to SVN/Subversion seamlessly. I love the side by side comparison and log views in Xcode.

On PC there are plugins for SVN/Subversion and git for Visual Studio and interfacing to an existing project is simple but creating a new one can be a bit of a pain in the GUI. I use AnkhSVN in VS 2010 Ultimate and WinMerge is my preferred comparison tool on the PC getting the tools set up where you can use them without distracting from the development task is 90% of the job.

Ultimately you end up using all of them if you fool with FOSS because the FOSS community uses all of them.

[peewee_RotA]

WinMerge is my preferred comparison tool on the PC getting the tools set up where you can use them without distracting from the development task is 90% of the job.

I forgot to mention that. Tortoise launches Winmerge seamlessly when it comes to comparisons.

I do have to mention, I have both Winmerge and the Starteam 2006 compare tool on my work computer and for how unbearably bad that starteam is, it's compare tool is really good. Even better than winmerge. 

[peewee_RotA]

Another thing that has always ticked me off about C#:

You are expected never to use destructors (because garbage collection is unpredictable and 90% of the time the objects you are cleaning up have already been deleted), however the concept of a destructor is vital to OOP...

So they added the concept of the disposable object.


So they took the tire off the existing wheel, reinvented a new wheel, and decided that you have to provide your own axles and brakes.

[quadz]

the concept of a destructor is vital to OOP...

Hmm...  I'd agree that destructors are vital to RAII.  But I'd say the concept of destructors is orthogonal to OOP.

For instance, Alan Kay coined the term Object Oriented, but I don't recall destructors in Smalltalk.

Indeed, most garbage collected OO languages I'm aware of don't support deterministic destructors, for technical reasons (conservative GC implementations.)


Regards,

quadz

[peewee_RotA]

In an attempt to abstract themselves into another dimension, common C# practice is to use Interfaces for everything and store concrete implementations in localized and easily "extendable" places.

Although this is a very clean approach, there is an issues when debugging.

msvc2010 C# only provides a "Go to Definition" button. This definition takes you directly to the declaration in the Interface. Yes I understand why. But the problem is that MSVC++ IDEs provide both a "Go To Definition" and "Go To Declaration."

By this understanding, interfaces can never have any definitions. Although it may not be possible to find the actual Definition of the concrete object that was assigned somewhere in the code, directing me to something that can never ever contain a definition is a useless and frustrating functionality that is contrary to it's historical use.

 

the concept of a destructor is vital to OOP...

Hmm...  I'd agree that destructors are vital to RAII.  But I'd say the concept of destructors is orthogonal to OOP.

For instance, Alan Kay coined the term Object Oriented, but I don't recall destructors in Smalltalk.

Indeed, most garbage collected OO languages I'm aware of don't support deterministic destructors, for technical reasons (conservative GC implementations.)


Regards,

quadz

You're right that I used the wrong term. It's a very basic need to be able to establish a lifetime of objects in order to properly clean up. In managed languages the memory concerns are not the issue, so cleaning up the memory during destruction is not necessary. However, a large number of objects still need lifetimes. Anything dealing with databases or IO need to have a cleanup even if the program crashes.

So not only is there this added Disposable interface concept in order to account for this, the cleanest method to ensure it is an elaborate "lifetime manager" built into the Unity Container. Although the lazy programmer can always just add giant try/catch/finally around the bootstrapper.