Why is the entry point of applications a static method?

A method declared static means that it belongs to the type and not the instance of an object.

In a C # Console Application, the entry point is static:

static void Main(string[] args) { ...  }

This is not just from C#, in Java it is the same concept:

public static void main(String[] args) { ... }

Is also not limited to console applications. A WPF project has a static entry point.

In the questions that already exist on the subject does not explain about the static beyond its obligation without justification and definition:

Why are application entry points static?

Is the application itself not initially an object instance of type Application or ConsoleApplication (i.e. whatever name I gave to the class containing the input method), for example?

Author: Vinicius Brasil, 2017-10-19

1 answers

Initially the application is not an instance of anything. And in a way that explains why the method is static.

Could be an instance method, there is nothing technically preventing it from doing this way, that's just how they chose it, perhaps because it was always so in other languages existing before C#, most of which even have the concept of classes and instantiation of objects.

Could more, could let define another method, maybe even with another signature, leaving until passing other arguments. Remember that you need to tell which type you should use as entry point . And it can have Main() in any type without it being an entry point.

Android instantiates objects and does what it needs. For the operating system model is more interesting. But traditional operating systems have always had a single way to launch an application. So I would say they chose so even for historical reasons, everyone was used to do so.

In non-object-oriented languages a function is used as an entry point and the static method is the same as a function.

I think understanding the use of the static method helps to understand this decision. Contrary to what oop ideologists preach, a static method is always simpler to deal with and it should be preferred always where it fits (it does not fit in a lot of situation). The Main() is a case that fits like a glove.

I don't see so much difficulty as they said in the comments, but it makes some sense. Simplification seems to me the best argument to avoid this functionality that would bring little or no advantage. Language developers are pragmatic and analyze the costs of implementing something, of complicating the language and the benefits that it will bring.

One point I think you can take into consideration is that you may want to call this Main() within your application. There you need to instantiate another object, because the object that started the application is owned by the CLR (unless it is passing it there and here in the application). If it is another instance, although it will physically call the same method, it is accessing another object, with possibly different data, it may not be what you want.

In C # you can use 4 different signatures (not simultaneously):

static void Main();
static void Main(string[] args);
static int Main();
static int Main(string[] args);

I put on GitHub for future reference.

In C # 7.1 can even more because Main() can be asynchronous.

In C# 9 you don't need to have this method explicit for simple scripts. Not that it ceased to be needed, the compiler puts it to you. Just do this for code throw away.

 12
Author: Maniero, 2020-06-23 15:43:57