locked
Abstract and Interface static members

    General discussion

  •     These are two features that I think really would help both coding and optimizing C#, and I don't know where to request these features and how best they would be implemented or why their missing, so I thought of putting them here for discussion.

        The first one is having the ability to use static members in abstract classes, abstract classes are mainly templates for classes, and their very usefull to maintain code integrity. So if I can have two non static classes with the same static members, then I should be able to define an abstract class with those static members and inherit from it, then the compiler could check if there were any inconcistencies between the two, and while coding just by creating a new class and inherit from the abstract I would have a skeleton for the new class.

        The second one is essencially the same but applied to interfaces, but here we have to diferent things, one is to have a normal interface but with static members so we could use it as a template for part of a class, instead of providing a skeleton for the whole class we would have just part, and the compiler could also check if there were any inconcistencies between the various classes that used the same interface. The other is to be able to have true static stateless interfaces, something in between the current interface implementation and extension methods, where the code of the interface would be unique for all the classes that used it, and I would only have to reference the interface in the class and not have to add any extra code for it.

        I know some of these can be partially achieved, but even so, most just make the code even less readable and don't provide true implementations or guarantee a compiler verification as for the first case.

    • Edited by BillyFB Wednesday, August 27, 2008 11:15 AM naming correction
    Tuesday, August 26, 2008 5:33 PM

All replies

  • By "herditate", do you mean "inherit"?

    You can have static members on abstract classes - you just can't have virtual static members or abstract static members. Likewise static members don't participate with interfaces in C#. I found it hard to follow what you propose they would add, but in many years of writing C# constantly, I have never missed any of these features. I'd love to understand more though... (could you perhaps re-phrase?).

    One thing that might help here is "extension methods" in C# 3; this allows you to provide implementation against an interface (possibly a generic interface), which any cosumers can then use. But if the implementing class decides to provide that method itself, then the compiler will start using the classes own implementation - the only real failing is that this is only done by the compiler - things like generics won't automatically find the specific implementations (assuming the generic method only knows about the extension method).


    Marc
    Tuesday, August 26, 2008 9:57 PM
  •     Marc, thanks for the correction, and I've also been codeding in C# almost from when it came out and projects have been getting more complex, as well as the better understanding and need for code simplyfication and optimization.

        What I miss and propose for the abstract classes, wich is specifically, the not supported virtual static members in an abstract class, is very usefull when you want to layout some sort of Framework in wich you need to guaranty that various classes have the same structure, exactly the same as you can do with normal asbtract classes and instance virtual members, but you want to be able to use statics just as to force the implementation of a static member by the class that inherits from that abstract. As I said I can have two classes with the same defenition of static members but then I have no way of making sure that they have the same signature (as in name, acepted and returned types).

        I hope this helps understanding it better.

    Wednesday, August 27, 2008 11:54 AM
  • BillyFB

    I fully agree, several years have passed now and we still cannot create a 'contract' that guarantees a class will implement a static member. That is all I need; to ensure a static member has been implemented on a class. I don't understand why no-one else thinks this would be useful.

    Friday, December 10, 2010 11:00 PM