Walter wrote:

> 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.

Agreed, but where you position the function could help. Top of programname.d for example.

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

Using this() appears more OO to me, I could be wrong. Since D is multiple paradigm, allowing structured main() or OO this() seems quite OK to me.

> 
> 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.

To me, WinMain() is useless (plus see how difficult it is to use in D as of now). Lately I've just been using main() and telling the linker it's a Windows app.
DLLs seem completely different. DllMain/DllEntryPoint isn't actually a "program driver" function, it's just a initialization/cleanup function. More like an event callback. DLLs wouldn't use this().


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

I was thinking this might lead to an interesting use for ~this()  as well.
But then, if the constructor (main) failed, then the destructor wouldn't be
invoked anyway (according to the D ctor/dtor rules)  ...


"Vathix" <vathix@dprogramming.com> wrote in message news:c1ibv8$1u5s$1@digitaldaemon.com...
> 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

Vathix wrote:
>
> Walter wrote:
>
>> 2) C/C++ tradition is for main().
> 
> Using this() appears more OO to me, I could be wrong. Since D is multiple paradigm, allowing structured main() or OO this() seems quite OK to me.

But a program's execution point isn't an OO concept, unless you want to support the idea of multiple entry points within a single application. Either way, I don't think it's entirely foreign as Java does this already.

> To me, WinMain() is useless (plus see how difficult it is to use in D as of now). Lately I've just been using main() and telling the linker it's a Windows app.
> DLLs seem completely different. DllMain/DllEntryPoint isn't actually a "program driver" function, it's just a initialization/cleanup function. More like an event callback. DLLs wouldn't use this().

Why not?  Using this() and ~this() seems to make sense as the C model doesn't have any natural support for release functionality.


Sean

In article <c1ir1t$2pr4$1@digitaldaemon.com>, Walter says...
>
>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.

I still don't know why we have "this" instead of "ctor".

Ant

Makes sense for that style of threading ... the ~this() would also make
sense in that context.


<resistor@mac.com> wrote in message news:c1iq2p$2o8m$1@digitaldaemon.com...
> 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.
> >
>
>

Isnt "this" more appropriate? It refers to
this particular Object that has been constructed doesnt it?
If you called it "ctor", would you then go

ctor.var;
instead of
this.var; ?

Phill.


"Ant" <Ant_member@pathlink.com> wrote in message news:c1j584$a54$1@digitaldaemon.com...
> In article <c1ir1t$2pr4$1@digitaldaemon.com>, Walter says...
> >
> >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.
>
> I still don't know why we have "this" instead of "ctor".
>
> Ant
>
>