Can't define static abstract string property

Question

I\'ve run into an interesting problem and am looking for some suggestions on how best to handle this...

I have an abstract class that contains a static method that accep

Answer 1

Elsewhere on this page, @Gusman proposes the nice solution distilled here:

abstract class AbstractBase { };

abstract class AbstractBase<T> : AbstractBase
{
    public static String AbstractStaticProp { get; set; }
};

class Derived1 : AbstractBase<Derived1>
{
    public static new String AbstractStaticProp
    {
        get => AbstractBase<Derived1>.AbstractStaticProp;
        set => AbstractBase<Derived1>.AbstractStaticProp = value;
    }
};

class Derived2 : AbstractBase<Derived2>
{
    public static new String AbstractStaticProp
    {
        get => AbstractBase<Derived2>.AbstractStaticProp;
        set => AbstractBase<Derived2>.AbstractStaticProp = value;
    }
};

Moving the static property from a non-generic to generic class means there is no longer necessarily a single global instance. There will be a unique AbstractStaticProp for each distinct type T, so the idea is that specifying the type of the derived class(es) themselves for T guarantees each of them generates a unique static for themselves. There are a few hazards to note with this, however.

• If for some reason it is not acceptable for AbstractBaseClass to be generic, then you've only moved the problem elsewhere (albeit more clearly distilled), because you still have to figure out how to statically call from AbstractBase to AbstractBase<T>.
• Mainly, there is nothing to enforce or require that any/every given derived class actually does "implement" the (psudo-) "overridden" static property;
• Related to this, since there is no compiler (polymorphic) unification going on here, correct signatures (method name, parameter arity, typing, etc.) for the "overridden" methods aren't enforced either.
• Although the generic parameter is intended to be "TSelf" of a derived class, in reality T is unconstrained and essentially arbitrary. This opportunizes two new classes of bug: if base class specification Y : AbstractBase<...> mistakenly references a different AbstractBase‑der­ived class X, the values of the "abstract static property" for X and Y will be incorrectly conflated -- and/or -- any usage call-site AbstractBase<T>.AbstractStaticProp with a mistaken type argument (such as DateTime) will spontaneously--and silently--demand a fresh new "instance" of the static property.

The last bullet point can be somewhat mitigated by adding a constraint on the generic base:

///                                v---- constraint added      
abstract class AbstractBase<TSelf> where TSelf : AbstractBase<TSelf>
{
    public static String AbstractStaticProp { get; set; }
};

This eliminates the possibility of class Derived2 : AbstractBase<DateTime> { /*...*/ }, but not the error class Derived2 : AbstractBase<Derived1> { /*...*/ }. This is due to a recurring conundrum that foils all attempts at constraining a generic type to some exact branch of the type-inheritance hierarchy:

The "TSelf problem"
Generic constraints are always at the mercy of the type arguments that are supplied, which seems to entail that it's impossible to construct a generic constraint that guarantees that some particular TArg within its scope refers to a type that is derived from itself, that is, the immediate type being defined.

The error in this case is an example of this; while the constraint on AbstractBase<TSelf> rules out incompatible disjoint types, it can't rule out the unintended usage Derived2 : AbstractBase​<Derived1>. As far as AbstractBase is concerned, the supplied type argument Derived1 satisfies its constraint just fine, regardless of which of its subtypes is deriving itself (im-)properly. I've tried everything, for years, to solve TSelf; if anyone knows a trick I've missed, please let me know!

Anyway, there are still a couple other points to mention. For example, unless you can immediately spot the problem in the following code, you'll have to agree that it's a bit dangerous:

public static new String AbstractStaticProp
{
    get => AbstractBase<Derived1>.AbstractStaticProp;
    set => AbstractBase<Derived2>.AbstractStaticProp = value;
}

Ideally, you want to get the compiler to do what it's meant to, namely, understand that all AbstractStaticProp property instances are related and thus somehow enforce their unification. Since that's not possible for static methods, the only remaining option is to eliminate the extra versions, effectively reducing the problem to the unification of just one, a vacuous operation, obviously.

It turns out that the original code is being too elaborate; the generic-base class approach wants to collapse on the simpler solution all by itself without having to explicitly request it, such as those new-marked properties seem to be doing with the qualification in AbstractBase<Derived1>.​AbstractStaticProp".

You can already refer to each respective independent copy of the static property by qualifying with the derived class name instead (in fact, @Gusman's test harness shows this), so the end result is that the property declarations in the derived class aren't necessary at all. Without further ado, here is the complete simplified version:

abstract class AbstractBase { };

abstract class AbstractBase<TSelf> : AbstractBase
    where TSelf : AbstractBase<TSelf>
{
    public static String AbstractStaticProp { get; set; }
};

class Derived1 : AbstractBase<Derived1> { };

class Derived2 : AbstractBase<Derived2> { };

This works identically to the code at the top. The test harness gives the same results as before.

static void Test()
{
    Derived1.AbstractStaticProp = "I am Derived1";
    Derived2.AbstractStaticProp = "I am Derived2";

    Debug.Print(Derived1.AbstractStaticProp);   // --> I am Derived1
    Debug.Print(Derived2.AbstractStaticProp);   // --> I am Derived2
}

Answer 2

Static members do not have polymorphism, so they can't be abstract. :(

If that's what you need, consider making a Singleton object, and reading the property off that object.

Answer 3

What you're trying to do is impossible, as others have mentioned.

I'd try something like this

public abstract class ProviderConfiguration : ConfigurationSection
{
    public string ConfigurationSectionName { get; set; }

    public static ProviderConfiguration Provider { get; set; }

    public static Configuration Current
    {
        get { return (Configuration)ConfigurationManager.GetSection(Provider.ConfigurationSectionName); }
    }
}

Then in practice:

public void DoStuff()
{
    var provider = new DerivedProviderConfiguration();
    ProviderConfiguration.Provider = provider;
}

Answer 4

Just use new to override a static method in a derived class. Nothing that makes new a bad thing to do for virtual methods and properties applies since the type name must be supplied:

public class BaseClass
{
    public static int Max { get { return 0; } }
}

public class InteriorClass : BaseClass
{
}

public class DerivedClass : InteriorClass
{
    public new static int Max { get { return BaseClass.Max + 1; } }
}

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("BaseClass.Max = {0}", BaseClass.Max);
        Console.WriteLine("InteriorClass.Max = {0}", InteriorClass.Max);
        Console.WriteLine("DerivedClass.Max = {0}", DerivedClass.Max);
        Console.ReadKey();
    }
}

Answer 5

Ok, this is not exactly to create an static abstract property, but you can achieve the desired effect.

You can get this by using generics:

public abstract class MyAbstractClass<T>
{
    public static string MyAbstractString{ get; set; }
    public static string GetMyAbstracString()
    {

        return "Who are you? " + MyAbstractString;

    }
}

public class MyDerivedClass : MyAbstractClass<MyDerivedClass>
{
    public static new string MyAbstractString
    { 
        get 
        { 
            return MyAbstractClass<MyDerivedClass>.MyAbstractString; 
        }
        set
        {
            MyAbstractClass<MyDerivedClass>.MyAbstractString = value;            
        }
    }

}


public class MyDerivedClassTwo : MyAbstractClass<MyDerivedClassTwo>
{
    public static new string MyAbstractString
    {
        get
        {
            return MyAbstractClass<MyDerivedClassTwo>.MyAbstractString;
        }
        set
        {
            MyAbstractClass<MyDerivedClassTwo>.MyAbstractString = value;
        }
    }

}


public class Test
{

    public void Test()
    {

        MyDerivedClass.MyAbstractString = "I am MyDerivedClass";
        MyDerivedClassTwo.MyAbstractString = "I am MyDerivedClassTwo";


        Debug.Print(MyDerivedClass.GetMyAbstracString());
        Debug.Print(MyDerivedClassTwo.GetMyAbstracString());


    }

}

So, calling the test class you will get:

"Who are you? I am MyDerivedClass" "Who are you? I am MyDerivedClassTwo"

So, you have an static method in an abstract class but the abstract value is different for each derived class, nice :D

Ok, so, what's going here? The trick is the generic tag, the compiler is generating a different abstract class for each derived type.

As I said it's not an abstract property, but you get all benefits of abstract static properties, which are programming static functions on your abstract class but using different static parameters per type.