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.


Riccardo De Agostini wrote:
> I know I am going against an already well-established standard... but it
> seems to me that calling constructors "this" and destructors "~this",
> although much better than the C++ way of using the class name, is not
> optimal.
> How about calling constructors "constructor" and destructors "destructor",
> which also makes the latter just one token instead of two?
> 
> class A
> {
>   constructor(int x) { }
>   destructor() { }
> }
> 
> Oh well, maybe I'm way too late for such a proposal, but anyway I tried...
> 
> Ric
> 
> 

This has been my opinion for ages, though I haven't publicly expressed it until now.

"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

..and by extension...

"this.constructor()" would call the constructor of this object
"otherObject.constructor()" would call the constructor of some otherObject

With the current syntax, I'm not entirely sure how I would manually call the constructor of a different object. Maybe "otherObject.this()"? That looks really wrong.

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.

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.

--Benji Smith

In article <bgd2c9$2pkp$3@digitaldaemon.com>, Riccardo De Agostini says...
>
>"Frank Wills" <name@host.com> ha scritto nel messaggio news:bgbpcj$1h6h$1@digitaldaemon.com...
>> For what it's worth, this() and ~this()
>> work fine for me. The "this" keyword, or
>> identifier is the name for what "this" is,
>> so from my perspective it's like calling
>> the /home directory "/home", or calling
>> a tree a "tree". It's correct, it makes
>> sense, and it's what I'm used to thinking.
>> In code you can even write "this.foo()", or
>> "this.somevar".
>
>I think you're very right as to the meaning of "this": it is a placehoder
>for an implicit reference to the object on which a method is called. But
>constructors and destructors are methods (although peculiar ones), not
>object references, so the current use of "this" is somewhat ambiguous.
>Not to mention the "~this" form for destructors: "~this" = "NOT
>constructor", or "the opposite of constructor"... it's C++ heritage and it
>sure looks like it; not Walter's style at all, as hundreds of other things
>in D demonstrate.
>Besides, D already identifies "peculiar" functions with keywords ("unittest"
>is an example), so introducing the "constructor" and "destructor" (or "ctor"
>and "dtor") keywords would just resolve the ambiguity "the D way".
>
>Ric
>
>

Calling them after the class causes lots and lots of trouble.  Consider when changing the name of the class, you have to find and fix all the names of the constructors and destructors.  Calling constructors and destructors gets harder.  Everything is no longer consistent (myclass.ctor) but dependent on the name of the class more than once (myclass.myclass) and then you still need a way to differentiate the destructor, so you end up needing myclass.~myclass.

The C++ way is bad.  It's bad for templates, it's bad for parsing, it's just plain wrong.  Delphi uses constructor and destructor, and it's not so bad. Longer, more typing than this and ~this, but perhaps more readable.

C++ also reserves all symbols starting with "_".

Sean

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bgd666$2tu2$1@digitaldaemon.com...
> If this and ~this have to go, and I can see the point (mixing the implicit object pointer name with the names of methods - very gauche), but why replace one oddity with another.
>
> Why not just go along with most other languages I can think of (C++, C#, Java) and call them after the class.
>
> Or, why not borrow from Python, and reserve all symbols beginning and
ending
> with __, as this would be useful for other special members (remembering
that
> the book's not yet been closed on acceptance of the current state of non-static operators).
>
> "Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in message news:bgbd5k$13fm$1@digitaldaemon.com...
> > I know I am going against an already well-established standard... but it
> > seems to me that calling constructors "this" and destructors "~this",
> > although much better than the C++ way of using the class name, is not
> > optimal.
> > How about calling constructors "constructor" and destructors
"destructor",
> > which also makes the latter just one token instead of two?
> >
> > class A
> > {
> >   constructor(int x) { }
> >   destructor() { }
> > }
> >
> > Oh well, maybe I'm way too late for such a proposal, but anyway I
tried...
> >
> > Ric
> >
> >
>
>

> The C++ way is bad.  It's bad for templates, it's bad for parsing, it's
just
> plain wrong.  Delphi uses constructor and destructor, and it's not so bad. Longer, more typing than this and ~this, but perhaps more readable.

Yes, I agree. (You'd think STLSoft-man would have had that thought, no?)

Paint me a different opinion. Now I want either

- constructor / destructor for all classes

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

- __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?)

I see nothing wrong with "this"/"~this"
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

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bgej3l$16gp$1@digitaldaemon.com...
> > The C++ way is bad.  It's bad for templates, it's bad for parsing, it's
> just
> > plain wrong.  Delphi uses constructor and destructor, and it's not so
bad.
> > Longer, more typing than this and ~this, but perhaps more readable.
>
> Yes, I agree. (You'd think STLSoft-man would have had that thought, no?)
>
> Paint me a different opinion. Now I want either
>
> - constructor / destructor for all classes
they just happen to be called this, ~this

> - constructor / finalize for non-auto classes & constructor / destructor
for
> auto classes
finalise could be !this (I know that is realy confusing)

>
> - __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?)
its just plain horrid (IMHO)
I would like to see finalise and unreachable but I dislike the use of
"normal" functions
(the difference being that unreachable is called when the GC sweeps [or
finds the object is unreachable], BUT before it considers deleting the
object so `this` can be put into a static or other reachable reference, and
finalise is called before the object is freed, and it is invalid to do
anythig with `this` but use it to read, it can not be written or passed to
any function that writes it anywhere, this does effect the GC impl, any
object with a unreachable can not be deleted for one cycle incase is becomes
live again)
I think any function/method that is "internal" should be marked an
syntactically different from "normal" functions
either by `internal void finalise() { ... }` or `operator finalise() {
.... }`
which I guess impies that this should be constructor new(...) and
~this should be destructor this(); or operator destructor { } // no params
but I'm happy the way it is imho its as good as delphi and better than the
other algol derived oo langs

Mike Wynn wrote:

> I see nothing wrong with "this"/"~this"
> 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

Ooh yes let's have that.  I use subclassing for constructor separation, but the fact that subclasses of the main class won't be able to have these separate constructors shows it as an incorrect usage of OOP, although there's nothing that can be done otherwise.

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");

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bgeojl$1bn0$1@digitaldaemon.com...
> Mike Wynn wrote:
>
> > I see nothing wrong with "this"/"~this"
> > 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
>
> Ooh yes let's have that.  I use subclassing for constructor separation, but the fact that subclasses of the main class won't be able to have these separate constructors shows it as an incorrect usage of OOP, although there's nothing that can be done otherwise.
>
> 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");

for consistance shouldn't
this() be this.new()  or at least they have the same meaning.

nit picking I know,  I vote for your syntax.

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

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bgeojl$1bn0$1@digitaldaemon.com...
> Mike Wynn wrote:
>
> > I see nothing wrong with "this"/"~this"
> > 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
>
> Ooh yes let's have that.  I use subclassing for constructor separation, but the fact that subclasses of the main class won't be able to have these separate constructors shows it as an incorrect usage of OOP, although there's nothing that can be done otherwise.
>
> 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");
>
>

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

Agreed.

Charles

"Frank Wills" <name@host.com> wrote in message 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.
>
>
> Riccardo De Agostini wrote:
> > I know I am going against an already well-established standard... but it
> > seems to me that calling constructors "this" and destructors "~this",
> > although much better than the C++ way of using the class name, is not
> > optimal.
> > How about calling constructors "constructor" and destructors
"destructor",
> > which also makes the latter just one token instead of two?
> >
> > class A
> > {
> >   constructor(int x) { }
> >   destructor() { }
> > }
> >
> > Oh well, maybe I'm way too late for such a proposal, but anyway I
tried...
> >
> > Ric
> >
> >
>

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) { ... }
    ...
}