> Why not just use static methods?

Because that would be one less thing to argue about

"BenjiSmith" <BenjiSmith_member@pathlink.com> ha scritto nel messaggio news:bge1dn$l1i$1@digitaldaemon.com...
> "this" is a reference to an object
> "constructor" should be the name of the constructor method for a class
> "destructor" should be the name of the destructor method for a class

Couldn't have been better said IMHO. Maybe, just because they are methods which actually perform actions, the ctor and dtor could be called "init" and "destroy" (or "init" and "finalize") respectively.

> I know somebody will say "constructors and destructors are called
automatically.
> There is no need to call them manually." Ah yes. Very true. But sometimes
there
> actually is a need to call constructors manually. I've done it.

That sounds strange at first, but since D itself is about being practical, I'd say that the right medicine is the one that cures, so I assume you did it for a reason and that's enough to me, as long as you're sure there could be no "D way" to do otherwise. In other words, do you think you had to do it because of some language-imposed limitation? Does D have the same limitation? What can be done about it in your opinion'

> Anyhow, besides just the fact that constructors and destructors are
semantically
> different that the "this" object self-referent, I really really dislike
that the
> tilde (~) is used as both the destructor prefix and the array
concatenation
> operator. Call me crazy.

Then I believe there are several crazy people here, including myself. :-)

Ric

"Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bgej3l$16gp$1@digitaldaemon.com...
> Paint me a different opinion. Now I want either
>
> - constructor / destructor for all classes

I'd stick to this one, possibly replacing the two keywords as per other proposals.

> - constructor / finalize for non-auto classes & constructor / destructor
for
> auto classes

Call me a bad programmer and an even worse analyst, but when I start coding a class I rarely know in advance if it will end up as an auto class. Besides, this would mean introducing even one more keyword and complicating the compiler's work.

> - __ctor__ / __finalize__ for non-auto classes & __ctor__ / __dtor__ for auto classes  (I know this one'll never get off the ground, but what the hell?)

Just plain ugly IMHO. I'm sorry to say this, because you of course have a reason for proposing that, but it's a punch in the eye to me.

Ric

"Mike Wynn" <mike.wynn@l8night.co.uk> ha scritto nel messaggio news:bgel0g$188r$1@digitaldaemon.com...
> I see nothing wrong with "this"/"~this"

I do, but that's no news. :-)

> the delphi way is nice as it allows more than one name for a constructor quite handy at times saves having two sub classes or adding a fake param

I think that's a great idea!! I'd add to that the possibility for a default, unnamed constructor, which would save typing in most cases, besides keeping all those non-Delphi-fans quiet ;-)

Ric

"Burton Radons" <loth@users.sourceforge.net> ha scritto nel messaggio news:bgeojl$1bn0$1@digitaldaemon.com...
> One syntax could be:
>
>     class File : Stream
>     {
>         this () // Creates the stream but doesn't fill it with anything.
>         this.Create (char [] filename) ...
>         this.Open (char [] filename) ...
>         this.OpenRead (char [] filename)
>         this.OpenAppend (char [] filename)
>     }
>
>     new File.Create ("foobar");

Quite sexy indeed. But I think the following is Kamasutra :-)

    class File : Stream
    {
        constructor () // Creates the stream but doesn't fill it with
anything.
        constructor Create (char [] filename) ...
        constructor Open (char [] filename) ...
        constructor OpenRead (char [] filename)
        constructor OpenAppend (char [] filename)
    }

"Frank Wills" <name@host.com> ha scritto nel messaggio news:bgdtf4$hdm$1@digitaldaemon.com...
> I like the universal simplicity of "this()" and
> "~this()". To my perspective it blends well with
> the simplicity and clairty of other such conventions
> as ".next()", ".first()", or "new".
> I see nothing particularly wrong with "constructor()"
> or "destructor()", it's just that to me, "this()"
> and "~this()" are shorter and simpler. And in
> languages, I like shorter and simpler a lot.

I do too. I often have a brief look at code I haven't been touching for
months (or even for years) to see how I solved a particular problem in
another context, so it's important to me that there are no ambiguities in
code, not even apparent ones. The visual pattern of a constructor
declaration should stimulate a different set of neurons than an object
reference, without having to think about it.
Or maybe I just don't have _that many_ neurons... :-)

Ric

That's _really_ nice.

--Benji Smith

In article <bgl5r4$192d$7@digitaldaemon.com>, Riccardo De Agostini says...

> I think the following is Kamasutra :-)
>
>    class File : Stream
>    {
>        constructor () // Creates the stream but doesn't fill it with anything.
>        constructor Create (char [] filename) ...
>        constructor Open (char [] filename) ...
>        constructor OpenRead (char [] filename)
>        constructor OpenAppend (char [] filename)
>    }
>
>

I like this also

"Benji Smith" <Benji_member@pathlink.com> wrote in message news:bglrmc$1s80$1@digitaldaemon.com...
> That's _really_ nice.
>
> --Benji Smith
>
> In article <bgl5r4$192d$7@digitaldaemon.com>, Riccardo De Agostini says...
>
> > I think the following is Kamasutra :-)
> >
> >    class File : Stream
> >    {
> >        constructor () // Creates the stream but doesn't fill it with
anything.
> >        constructor Create (char [] filename) ...
> >        constructor Open (char [] filename) ...
> >        constructor OpenRead (char [] filename)
> >        constructor OpenAppend (char [] filename)
> >    }
> >
> >
>
>

Well, it's not a direct translation.  ;)

Certainly that would work, but you'd have to have that default constructor available and some way of initializing the class data from outside the class (in the static methods) which I guess isn't too terribly bad.  At least they're static class members, not some random global function.

Sean

"Andy Friesen" <andy@ikagames.com> wrote in message news:bgk80p$djr$1@digitaldaemon.com...
> Sean L. Palmer wrote:
> > Yeah I hate the way it has to be done in C++ using overloading:
> >
> > enum cfCreate { Create };
> > enum cfOpen { Open };
> > enum cfOpenRead { OpenRead };
> > enum cfOpenAppend { OpenAppend };
> >
> > class File : public Stream
> > {
> >       File(); // Creates the stream but doesn't fill it with anything.
> >       File(cfCreate, char const* filename);
> >       File(cfOpen, char const* filename);
> >       File(cfOpenRead, char const* filename);
> >       File(cfOpenAppend, char const* filename);
> > };
> >
> >  File* f = new File(Create,"foobar");
> >
> > Aside from the obvious namespace pollution and potential for
inefficiency
> > (the compiler isn't required to eliminate the unused parameters) it also can't be done in D so easily.  D enums have to be explicitly qualified.
> >
> > I'd be for named constructors, if suitable syntax could be found.
> >
> > Sean
>
> Why not just use static methods?
>
> class File : Stream
> {
>      static File OpenAppend(char[] fileName) { ... }
>      ...
> }