2 comments
.NET 
One thing that has amazed me since I learned Java and C# is the way history keeps interfering with ‘modern’ languages. The first thing you learn when picking up a new language is the famous Hello World. The ‘Hello World’ – code in Java and C# is very similar:
|
Java:
|
C#
|
|
public class Hello
{
public static void main(String[] args) {
System.out.println(“Hello, world!”); } } |
class Hello
{ public static void Main(string[] args) { System.Console.WriteLine(“Hello, world!”); } } |
In both sources there is a class that contains a static method called Main. This is the entry point of the application. In other words: When we ‘start’ the application the Main method is started. Starting the application is different in Java and C#:
|
Java:
|
C#
|
|
c:>java.exe Hello.class
Hello, world!
c:>_
|
c:>Hello.exe
Hello, world!
c:>_
|
As you can see, to start a Java program you instruct the Java environment to run a class whereas .NET applications have a Main marked (by the compiler) that will be started by the .NET environment.
Now, who started taking Main for granted? Wouldn’t it be more sensible, logical, Object Oriented to have a constructor as entry point? So hereby I suggest the following brand new language E# (sorry couldn’t resist):
|
E# Hello World
|
E# Execution
|
|
public class Hello
{
public void Hello(string[] args)
{
System.Console.WriteLine(“Hello, World!”);
}
}
|
c:>MyApplication.exe Hello
Hello, World!
c:>_
|
Note that by passing the name of the class I am now able to choose what class will be started (a bit like Java) and a more Object Oriented approach by instantiating an object (The Program).
2 comments
Luckily we have c/c++ to blame on!
But then again.. We we take a look at IOC containers then most behave through static methods and act like factory objects. So having a static Main method does reflect a bit to a factory pattern although it won’t return an object but an outcome.
I propose to keep it the way it is :-). Contructors can’t return values thus our environment would need to know what exceptions are. They now expect a integer return value and I really don’t want to convert all those legacy .bat and .cmd files to catch exceptions… hehe..
Ramon Smits
This E# has some confusing syntax, starting a constructor with "void". 😉
Actually returning an error code using exceptions would not be that difficult. The E# API designer could propose a standard ApplicationException(int errorcode, String message) which, if thrown would end the program using exceptions.
There is one problem though, which is very much an OO violation. The Hello object never reaches a constructed state because the main loop is in the constructor body. Traditionally, you would only use the constructor to bring an object to a valid invariant by validating input and initialization, not to perform any real work.
Maybe the language designer of P# thinks of this:
public class Hello
{
private string greeting;
public Hello(string[] args)
{
greeting = args[0];
}
[ApplicationRunMethod]
public void RunHello()
{
System.Console.WriteLine("Hello, " + greeting);
}
}
In this example the object gets constructed and initialized in the constructor, and the logic runs in a separate method, marked with an attribute so the runtime knows which method to invoke.
Come to think of it, maybe static main() isn’t that bad after all. 😉
Peter Hendriks