Replies: 7 comments
-
Interesting to consider what happens when you remove the |
Beta Was this translation helpful? Give feedback.
-
That was my first thought, too. It's theoretically unnecessary as long as the class never loses it's static-icity. |
Beta Was this translation helpful? Give feedback.
-
It was an intentional decision when we did static classes. First, it remains very clear that the member is static when you look at it in isolation. Second, it keeps the design space open for us in case we ever feel like there would be some value in a member not marked with 'static' in a static-class that would have some new meaning. |
Beta Was this translation helpful? Give feedback.
-
This would make refactoring of such static classes to non-static classes a nightmare. Usually in this case most methods can stay static and only a few have to be changed. |
Beta Was this translation helpful? Give feedback.
-
I think the refactoring issue is overstated. Even if you took a static class' default static content and put it in a non-static class, it probably would not break the code; it would just stop being static. Does anyone have a really shining example of how it would make it unworkable? To tell the truth, changing method modifiers is a routine activity anyways; access modifiers, types, and static vs non-static... it's not a big deal. Cyrus' answer is comparatively more persuasive to me, as it implies the team was withholding that option in order to be use "non-static members of a static class" for a different semantics. On the other hand, I would argue that would be the worst option of all since it would introduce entirely new semantics to what we already have 2 competing (and at least so far exhaustive) semantics -- static and non-static. All-in-all, I do accept that the case for default static members isn't the strongest one, (i.e. vs the inertia to keep things as they are), but given that we already have stuff like expression bodied methods (which serves no real purpose other than reduce clutter a bit), I think the case for default static members is just as strong -- to reduce potential clutter in code. The idea of using "non-static members in static classes" for other semantics, IMO, again is really a bad one and I don't think after all these years it's something we should be holding onto. Thanks for all replies guys. |
Beta Was this translation helpful? Give feedback.
-
Just for the record, there is already one thing you can make non-statically inside a static class: A nested type. Not really a member of the static class, but it works syntactically. public static class Convenience
{
public static readonly IEqualityComparer<Foo> FooComparer { get; } = new HiddenImplementation();
private class HiddenImplementation : EqualityComparer<Foo>
{
//....
}
} |
Beta Was this translation helpful? Give feedback.
-
Same goes for delegates, enums, interfaces, and other types. In a sense though, nested types are always static with respect to the containing type. You can't make them non-static with respect to the containing type. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Static classes can only have static members, however we are required to mark each member with the "static" modifier. Wouldn't it be cleaner to have members be static by default? (while perfectly backwards compatible)
E.g., for class:
static class A { **static** int f(int x) => x +1; }
Make the "static" be unnecessary.
Beta Was this translation helpful? Give feedback.
All reactions