C# has made me sad :(

Pages: 12
How is a public static function dependent on any class? You can call it from any class without instantiating any class in particular

It lives within a certain class I mean. Using (className).(functionName) seems like a round-about way of trying to achieve the same thing? Wouldn't it make more sense to just have the function out in the global namespace where you can just call it if you need the whole program to have to access to it?
I may not agree with some of the design choices MS made when they created C#, but then C++ has its fair share of "what were they thinking" design oops. Done by years and years of planning by committee.
Last edited on
Wouldn't it make more sense to just have the function out in the global namespace where you can just call it if you need
I don't understand, though. How is Utility.O() not just calling the function? What else does that do besides call the function? You say it's roundabout, but is it? Is it very significant for your program that you have one particular string of characters in front of the parentheses instead of a different one?
I understand the desire for free functions instead of forcing a class wrapper around them (as a pseudo-namespace restriction). But as Furry Guy suggests, at the end of the day there's not much we can do.

If you really want an answer for "why" the restriction is in place to begin with, I'm sure you could search some developer blogs or something. Eric Lippert might be the most famous C# guy with information.
https://docs.microsoft.com/en-us/archive/blogs/ericlippert/

Here's some text from a 404'd blog page, which was also copied to SO:
https://stackoverflow.com/questions/1024171/why-c-sharp-is-not-allowing-non-member-functions-like-c
I am asked "why doesn't C# implement feature X?" all the time. The answer is always the same: because no one ever designed, specified, implemented, tested, documented and shipped that feature. All six of those things are necessary to make a feature happen. All of them cost huge amounts of time, effort and money. Features are not cheap, and we try very hard to make sure that we are only shipping those features which give the best possible benefits to our users given our constrained time, effort and money budgets.

I understand that such a general answer probably does not address the specific question.

In this particular case, the clear user benefit was in the past not large enough to justify the complications to the language which would ensue. By stricting how different language entities nest inside each other we (1) restrict legal programs to be in a common, easily understood style, and (2) make it possible to define "identifier lookup" rules which are comprehensible, specifiable, implementable, testable and documentable.

By restricting method bodies to always be inside a struct or class, we make it easier to reason about the meaning of an unqualified identifier used in an invocation context; such a thing is always an invocable member of the current type (or a base type).

I think he makes some good points.
Last edited on
Why a particular feature found in one programming language isn't in another newer one can usually be found in what problems the newer language was created [to solve] in the first place.

With C# a not insignificant reason was so MS had a replacement for their increasingly joke of a GUI language Visual Basic, as well as being a rival for C++. Flavored by some Java squeezings for a smidgen of extra syntax tanginess.
Last edited on
You say it's roundabout, but is it?

If a function can be called from outside the class, why is there no option to just make the function a stand-alone?

@Ganda @Furry Guy

I get that, this was just a small thing, especially compared to my quarrel with Lists.
what problems the newer language was created for in the first place.

C# was created to solve legal problems :P
If a function can be called from outside the class, why is there no option to just make the function a stand-alone?
You could ask similar questions of so many features in so many languages... But the simple answer is that C# is purely object oriented. The only things that can exist at top-level are classes (and enums).
C# is purely object oriented.

Something C++ is not, it inhabits both worlds of procedural programming and OOP, for either the benefit or detriment as the case may be.

My experience with C# certainly doesn't make me an instant fan about the language. Never will.

C# was created to solve legal problems :P

M$ certainly is as eager to pound the legal buttons as is Disney.
Last edited on
Topic archived. No new replies allowed.
Pages: 12