This has been in the back of my mind for awhile and I've finally decided it's not a bad idea: Having the program entry-point be this() instead of main(). You'll see how it fits in well with how we do classes, static this() and instance this(). Module this() would be the instance of the program. It would take either no parameters or char[][] like main, and have no return value.

this(char[][] args)
{
   printf("hello world %d args.", args.length);
}

What about main's int error code return value, you may ask? This isn't actually needed anymore, because we throw an exception on error. The exception handler that wraps this() would catch it and return an error code, whereas if this() cleanly returns, it would return 0. Kind of like this:

//real, hidden main
int main(char[][] args)
{
   int result = 0;
   try
   {
      this(args); //call module this
   }
   catch(Object o)
   {
      o.print();
      result = 1; //error!
   }
   return result;
}

This seems to be more OO, and main() could still be allowed for old time sake and for more structured programs.


-- 
Christopher E. Miller
www.dprogramming.com
irc.dprogramming.com #D

..and if I have a group of interrelated modules dropped on me which implement multiple executables (src\dmd ?) and I want to find out where to start sorting things out, do I have to search through and find all the naked 'this' occurrences?

In article <c1ibv8$1u5s$1@digitaldaemon.com>, Vathix says...
>
>This has been in the back of my mind for awhile and I've finally decided it's not a bad idea: Having the program entry-point be this() instead of main(). You'll see how it fits in well with how we do classes, static this() and instance this(). Module this() would be the instance of the program. It would take either no parameters or char[][] like main, and have no return value.
>
>this(char[][] args)
>{
>    printf("hello world %d args.", args.length);
>}
>
>What about main's int error code return value, you may ask? This isn't actually needed anymore, because we throw an exception on error. The exception handler that wraps this() would catch it and return an error code, whereas if this() cleanly returns, it would return 0. Kind of like this:
>
>//real, hidden main
>int main(char[][] args)
>{
>    int result = 0;
>    try
>    {
>       this(args); //call module this
>    }
>    catch(Object o)
>    {
>       o.print();
>       result = 1; //error!
>    }
>    return result;
>}
>
>This seems to be more OO, and main() could still be allowed for old time sake and for more structured programs.
>
>
>-- 
>Christopher E. Miller
>www.dprogramming.com
>irc.dprogramming.com #D

So in a multi-module program, which "this" should the compiler make "main?"


Sean

Sean Kelly wrote:
> So in a multi-module program, which "this" should the compiler make "main?"
> 
> 
> Sean
> 

Only put it in one module of the program, like main.


-- 
Christopher E. Miller
www.dprogramming.com
irc.dprogramming.com #D

Vathix wrote:
> Sean Kelly wrote:
> 
>> So in a multi-module program, which "this" should the compiler make "main?"
>>
>>
>> Sean
>>
> 
> Only put it in one module of the program, like main.
> 
> 

As first apporach you could make a global this an alias of main.

Stephan

Vathix wrote:
> 
> Only put it in one module of the program, like main.

So does this mean I could only have one module "this" in the entire project?  Or would this be based on the parameters passed?


Sean

Sean Kelly wrote:
> So in a multi-module program, which "this" should the compiler make "main?"
> 
> Sean

I found this at http://digitalmras.com/d/module.html:


"The order of static initialization is implicitly determined by the import declarations in each module.  Each module is assuemd to depend on any imported modules being statically constructed first.  Other than following that rule, there is no imposed order on executing the module static constructors.

Cycles (circular dependencies) in the import declarations are allowed as long as not both of the modules contain static constructors or static desctructors. Violation of this rule will result in a runtime exception."


So I would say that the "main" this() of the program should be the last one to be called in the ordering of constructors.  (I'm assuming, though, that in reality it is the first to be called...and that its implementation automatically calls the constructors for all others.)


I actually like this idea a lot, at least in theory.  I would like to have the "main" this stand out from all other this() functions.  So I would lean toward a required "main" keyword:

main this(char[][] args) {...}

but now we've gotten back to something that really is a main() function.  So I'm not convinced that we've really gained anything.


Still, I would like to have this discussed some more.  Let's see what good ideas turn up here.

What could be done is to create a syntax where each module can specify which imported modules are absolutely required to be initialized before its this() is run.

Thus if one module imports another, but doesn't actually require it for initialization, it could safely not "require" that module.  The this() which replaces the main() would just have to "require" every other module.

This could actually lead to an interesting new threading paradigm, if the this() of each module runs in a separate thread.  It reminds me of a microkernel: each separate component operates in its own thread, and the order they are started in is determined by requirement lists.

Just some random ideas though.

Owen

In article <c1imsp$2ibb$1@digitaldaemon.com>, Russ Lewis says...
>
>Sean Kelly wrote:
>> So in a multi-module program, which "this" should the compiler make "main?"
>> 
>> Sean
>
>I found this at http://digitalmras.com/d/module.html:
>
>
>"The order of static initialization is implicitly determined by the import declarations in each module.  Each module is assuemd to depend on any imported modules being statically constructed first.  Other than following that rule, there is no imposed order on executing the module static constructors.
>
>Cycles (circular dependencies) in the import declarations are allowed as long as not both of the modules contain static constructors or static desctructors. Violation of this rule will result in a runtime exception."
>
>
>So I would say that the "main" this() of the program should be the last one to be called in the ordering of constructors.  (I'm assuming, though, that in reality it is the first to be called...and that its implementation automatically calls the constructors for all others.)
>
>
>I actually like this idea a lot, at least in theory.  I would like to have the "main" this stand out from all other this() functions.  So I would lean toward a required "main" keyword:
>
>main this(char[][] args) {...}
>
>but now we've gotten back to something that really is a main() function.
>  So I'm not convinced that we've really gained anything.
>
>
>Still, I would like to have this discussed some more.  Let's see what good ideas turn up here.
>

It's an interesting idea, and it can work. But I see a few problems:

1) When I get a large block of source, I usually have to grep around looking
for where main() is. With this() instead, I'd have to filter out a lot of
false hits.

2) C/C++ tradition is for main().

3) DLL's and Windows apps have differently named main() functions, the
reason for the difference is so that different startup code can be called
in.

>1) When I get a large block of source, I usually have to grep around looking
>for where main() is. With this() instead, I'd have to filter out a lot of
>false hits.

True.  But it could also lead to some very interesting possibilities in terms of parallelism if taken to its fullest extent.

>2) C/C++ tradition is for main().

Yes, that's the biggest hurdle I see.  It would take some serious getting used to.  I'd imagine a programmer should still be able to use main() if he so desired.

>3) DLL's and Windows apps have differently named main() functions, the
>reason for the difference is so that different startup code can be called
>in.

I don't think that's a big hurdle.  If the programmer uses the this() syntax, the compiler is going to have to generate a stub main for him anyways.  In this case, the compiled just makes a stub main with the appropriate name for Win32.

Owen