3 ms·

It's a good point about auto-complete I hadn't considered, maybe globals could have some obvious name thing going on, I hate this suggestion but for example an

It's a good point about auto-complete I hadn't considered, maybe globals could have some obvious name thing going on, I hate this suggestion but for example an underscore prefix. Some examples of where global functions might make sense, the Main function of a console application doesn't need to be in a class, or the general Utils and Helpers approach soon becomes cumbersome, you end up having to name things that don't really need names. While static classes can help organise these global functions you also end up playing the naming game when you don't need to. It might not be any improvement but it's an interesting thought exercise to imagine functions living in just a namespace, not a class. I think in C# static still doesn't give you enough guarantees at either the class or member level. A static class can still have public static mutable members which is a horrible code smell. C# contains enough flexibility to do the things I want, e.g. make things static and readonly, but it's a lot of additional typing and I'd be interested in seeing the model reversed, e.g. immutable defaults with something like `public mutable class Foo` which I remember having seen in other places (F#?).

Const-me 7y ago
> you end up having to name things that don't really need names. Strictly speaking namespaces don’t need names, either. But for medium to large projects they’re still useful, and enforced by the IDE. > to imagine functions living in just a namespace, not a class. You can place them into a namespace on the consumer side of the API, with `using static`. While not the same, might be good enough in practice: you normally have multiple `using` statements on top, for namespaces. > I'd be interested in seeing the model reversed, e.g. immutable defaults with something like `public mutable class Foo` I wouldn’t want immutable defaults, but I do want readonly classes and structures, with readonly being part of the type system. BTW, the new value tuples with named fields is a step in the right direction https://blogs.msdn.microsoft.com/mazhou/2017/05/26/c-7-series-part-1-value-tuples/ https://blogs.msdn.microsoft.com/mazhou/2017/05/26/c-7-serie... Useful but limited, I would prefer real immutable classes & structures. Currently I have to create them manually, mark all fields public readonly, implement the constructor, that’s more typing than I’d like.

Const-me 7y ago

> you end up having to name things that don't really need names. Strictly speaking namespaces don’t need names, either. But for medium to large projects they’re still useful, and enforced by the IDE. > to imagine functions living in just a namespace, not a class. You can place them into a namespace on the consumer side of the API, with `using static`. While not the same, might be good enough in practice: you normally have multiple `using` statements on top, for namespaces. > I'd be interested in seeing the model reversed, e.g. immutable defaults with something like `public mutable class Foo` I wouldn’t want immutable defaults, but I do want readonly classes and structures, with readonly being part of the type system. BTW, the new value tuples with named fields is a step in the right direction https://blogs.msdn.microsoft.com/mazhou/2017/05/26/c-7-series-part-1-value-tuples/ https://blogs.msdn.microsoft.com/mazhou/2017/05/26/c-7-serie... Useful but limited, I would prefer real immutable classes & structures. Currently I have to create them manually, mark all fields public readonly, implement the constructor, that’s more typing than I’d like.