base::StaticMember syntax

[TahirAhmadov]

If the base class is a generic type, especially with many type arguments, referencing static members on it (this is specifically a pain point when "hiding" those static members) becomes very long:

class MyClass : BaseClass<string, int, OtherClass<double, decimal>>
{
  protectec static new readonly string Name = BaseClass<string, int, OtherClass<double, decimal>>.Name + " MyClass";
}

It would be much easier to do something like this:

class MyClass : BaseClass<string, int, OtherClass<double, decimal>>
{
  protectec static new readonly string Name = base::Name + " MyClass";
}

Needless to say, I'm not stuck on base:: syntax, but it does look like it can work - not ambiguous, easy to write, etc.

[jnm2]

How painful is it to declare an alias in the file?

[TahirAhmadov]

If I only need to reference a base static member once per class, declaring an alias is actually more work; if I do it twice, it just about pays off; really, it only makes sense once you have 3 references or more per class. (I just realized that the "base" specifier in the class declaration itself can use the alias, which does help the alias case somewhat.)

In my code base, I happen to have a large number of classes, and usually 1 (very rarely 2, and almost never 3) references to base static members.

Besides, what if the type arguments are generic arguments of the child class? I have quite a few of those, as well.

using Base = BaseClass<TEntity, TParent, TControl>; // error

class MyClass<TEntity, TParent, TControl> : BaseClass<TEntity, TParent, TControl>
{
  protectec static new readonly string Name = Base.Name + " MyClass";
}

[jnm2]

Good followup example. The "very rarely 2" part is getting my attention.

[huoyaoyuan]

base. follows the C# style. Does it conflict to any existing stuff?

[jnm2]

It would probably not be possible to access static methods with the same name as instance methods, or else overload resolution would have to be considering both sets for the same syntax which could be a breaking change.

[TahirAhmadov]

@jnm2 is right, if we were to add this, then it should be usable in all expressions, and base. becomes ambiguous.

[HaloFour]

Reminds of me this proposal:

#1055

If there was a keyword to qualify static members without the full type name maybe it could be extended to this case?

protected static new readonly string Name = base(class).Name + " MyClass";

[TahirAhmadov]

Not as short as base::, but still much better than writing it all out, I can live with this approach. And I'm one of those pedants who likes to prefix with this. (partially a habit from JavaScript) and I would like to be able to prefix with class., too. class. is definitely a lower priority, but together with this, it becomes more valuable. I always prefer a comprehensive approach instead of a narrow feature.

[TahirAhmadov]

I just came across another reason why it's desirable to have this syntax - copying and pasting classes. Yes, I know 2 classes should not be a copy of each other, but I frequently start working on adjacent features by using an existing closely-related class as a template - think another UI element, etc. When both original and "cloned" classes use this pattern (reference a hidden base static member), and the base class changes, I have to remember to change those references (which I sometimes forget to do). If those references were base:: (or base(class)., everything would work automatically in this situation.