"Walter" <walter@digitalmars.com> wrote in message news:9vhs0a$1t8o$1@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:9vhkt5$1pfv$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message news:9vglbk$16vc$1@digitaldaemon.com...
> >
> > > You should get an error message.
> >
> > Then why "static" is needed, since there are no non-static module constructors?
>
> For consistency with the way they are defined for classes.

From my POV, module is sort of class, with only one instance existing. As such, it might have a =non-static= constructor.

But in general, it's a matter of personal taste. So far, why not just define "static" to be an option for module constructors? And everybody would be satisfied...

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vi1fi$2032
> From my POV, module is sort of class, with only one instance existing. As such, it might have a =non-static= constructor.
>
> But in general, it's a matter of personal taste. So far, why not just define "static" to be an option for module constructors? And everybody would be satisfied...

While that will certainly work, I'd like to stick with one way of doing things at least in the initial release!

Because you don't want to publish the module ctor and dtor functions to be called by other modules, perhaps.

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vi1fi$2032$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9vhs0a$1t8o$1@digitaldaemon.com...
> >
> > "Pavel Minayev" <evilone@omen.ru> wrote in message news:9vhkt5$1pfv$1@digitaldaemon.com...
> > > "Walter" <walter@digitalmars.com> wrote in message news:9vglbk$16vc$1@digitaldaemon.com...
> > >
> > > > You should get an error message.
> > >
> > > Then why "static" is needed, since there are no non-static module constructors?
> >
> > For consistency with the way they are defined for classes.
>
> From my POV, module is sort of class, with only one instance existing. As such, it might have a =non-static= constructor.
>
> But in general, it's a matter of personal taste. So far, why not just define "static" to be an option for module constructors? And everybody would be satisfied...

That's neat and all, but I'm talking about individual class objects.  Not necessarily modules (though it's nice to see something akin to Turbo Pascal's units again instead of this nightmarish #include bullshit!)

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vfhhd$j5q$1@digitaldaemon.com...
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:9vfc86$g7k$1@digitaldaemon.com...
>
> > Something I'm really going to miss I think in D is guaranteed order of destruction.  I oftentimes use a class as a convenient way to
> automatically
> > run ctor and dtor code for initialization and cleanup.  I have to use
> smart
> > pointer classes to get that, but it's worth it.  In D order of
destruction
> > cannot be guaranteed at all.  Maybe I'll get used to it... calling
> explicit
> > Init and Exit functions instead of ctors/dtors etc.  But it sure was
nice
> to
> > have all that cleanup work done automatically by the compiler,
especially
> > what with exceptions going off and everything, you don't have to put as
> much
> > work into each function exit point because you know the state of the
> system
> > will be consistent at each step.
>
> Don't forget about static constructors/destructors. They do exactly what you want, and the latest spec (one with the alpha) defines strict order of their execution:
>
> "The order of static initialization is implicitly determined by the import declarations in each module. Each module is assumed 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."
>
> Since static constructors for modules you depend on are always called first, it should be exactly what's needed to initialize a module.

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9vkf3j$bb7$1@digitaldaemon.com...

> That's neat and all, but I'm talking about individual class objects.  Not necessarily modules (though it's nice to see something akin to Turbo Pascal's units again instead of this nightmarish #include bullshit!)

What's wrong with objects? Operator new calls the constructor, garbage
collector will then remove the object, calling destructor for you,
or you can explicitly request to remove the object you want.

That's a good reason. Wish I'd thought of it <g>.

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9vkevi$b24$1@digitaldaemon.com...
> Because you don't want to publish the module ctor and dtor functions to be called by other modules, perhaps.
>
> Sean
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:9vi1fi$2032$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message news:9vhs0a$1t8o$1@digitaldaemon.com...
> > >
> > > "Pavel Minayev" <evilone@omen.ru> wrote in message news:9vhkt5$1pfv$1@digitaldaemon.com...
> > > > "Walter" <walter@digitalmars.com> wrote in message news:9vglbk$16vc$1@digitaldaemon.com...
> > > >
> > > > > You should get an error message.
> > > >
> > > > Then why "static" is needed, since there are no non-static module constructors?
> > >
> > > For consistency with the way they are defined for classes.
> >
> > From my POV, module is sort of class, with only one instance existing. As such, it might have a =non-static= constructor.
> >
> > But in general, it's a matter of personal taste. So far, why not just define "static" to be an option for module constructors? And everybody would be satisfied...
>
>
>

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9vkf3j$bb7$1@digitaldaemon.com...
> That's neat and all, but I'm talking about individual class objects.  Not necessarily modules (though it's nice to see something akin to Turbo Pascal's units again instead of this nightmarish #include bullshit!)
>
> Sean

I know what you mean - you want to declare some functionality, and then have some other functionality performed upon the closing }. I use just such a thing for some simple timers, and some debug classes in C++. That feature isn't in D, however.

There is a whole philosophy based on it. Check out 'Resource Management' at
www.relisoft.com
- Rajiv

"Walter" <walter@digitalmars.com> wrote in message news:9vlrcd$16lh$2@digitaldaemon.com...
>
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:9vkf3j$bb7$1@digitaldaemon.com...
> > That's neat and all, but I'm talking about individual class objects.
Not
> > necessarily modules (though it's nice to see something akin to Turbo Pascal's units again instead of this nightmarish #include bullshit!)
> >
> > Sean
>
> I know what you mean - you want to declare some functionality, and then
have
> some other functionality performed upon the closing }. I use just such a thing for some simple timers, and some debug classes in C++. That feature isn't in D, however.
>
>

"Rajiv Bhagwat" <dataflow@vsnl.com> wrote in message news:9vml4d$1nlb$1@digitaldaemon.com...

> There is a whole philosophy based on it. Check out 'Resource Management'
at

The reason was that C++ doesn't offer you any built-in capabilities of things such as smart-pointers, and resource management in general - which is probably what most demand. In D, however, you can be sure that all trash will be occasionaly collected by the GC. Of course, in cases where order is important, you have to delete everything explicitly... but I personally have always considered the way "always release after use" a good programming practice...

I forgot you can manually delete an object in D.

Still you don't really get the automatic dtor behavior... I suppose you could have one object that must be dtor'd after another object, to hold a pointer to said object.

Anyway, nothing that would prevent one from using the language.

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9vkv3m$let$3@digitaldaemon.com...
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:9vkf3j$bb7$1@digitaldaemon.com...
>
> > That's neat and all, but I'm talking about individual class objects.
Not
> > necessarily modules (though it's nice to see something akin to Turbo Pascal's units again instead of this nightmarish #include bullshit!)
>
> What's wrong with objects? Operator new calls the constructor, garbage
> collector will then remove the object, calling destructor for you,
> or you can explicitly request to remove the object you want.