www.digitalmars.com         C & C++   DMDScript  

D - this

reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
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
Jul 31 2003
next sibling parent Patrick Down <Patrick_member pathlink.com> writes:
In article <bgbd5k$13fm$1 digitaldaemon.com>, Riccardo De Agostini says...
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
Here, here! I've wanted to say the same thing for a long time but figured that I wouldn't get any support for it. Thanks for bringing it up.
Jul 31 2003
prev sibling next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
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?
The benefit of this and ~this over a name is that it doesn't take any symbols from the user.
Jul 31 2003
parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Burton Radons" <loth users.sourceforge.net> ha scritto nel messaggio
news:bgbg51$16ls$1 digitaldaemon.com...
 The benefit of this and ~this over a name is that it doesn't take any
 symbols from the user.
You're of course right. My personal opinion, though, is that the advantages in both readability and formal correctness would overweigh the inconvenience of not being allowed to name a variable or function "constructor" or "destructor" (or whatever they may be in the end). Ric
Jul 31 2003
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
I second that (what about "ctor" and "dtor"?)

In article <bgbd5k$13fm$1 digitaldaemon.com>, Riccardo De Agostini says...
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
Jul 31 2003
next sibling parent reply Frank Wills <name host.com> writes:
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".

Ant wrote:
 I second that (what about "ctor" and "dtor"?)
 
 In article <bgbd5k$13fm$1 digitaldaemon.com>, Riccardo De Agostini says...
 
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
Jul 31 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"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
Jul 31 2003
parent reply BenjiSmith <BenjiSmith_member pathlink.com> writes:
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
Aug 01 2003
parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"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
Aug 04 2003
prev sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Ant" <Ant_member pathlink.com> ha scritto nel messaggio
news:bgbnbp$1elo$1 digitaldaemon.com...
 I second that (what about "ctor" and "dtor"?)
Great when typing; maybe a bit confusing when having a quick look at source code. Just my personal taste, anyway: from a practical point of view they may be preferrable. Ric
Jul 31 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
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.


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
Aug 01 2003
next sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bgd666$2tu2$1 digitaldaemon.com...

 Java) and call them after the class.
<IMHO> First, because the class name is the class name, just as "this" is the implicit object reference name. Second, because "~myclass" looks as "smart" as bit shift operators in iostreams. You know what I mean :) The rationale could be that, by destroying an object, you apply a not operator to its existence... like Terminator saying "I'm gonna apply a not operator to you" :-) Forgivable, from an android. Third, "the D way". Ctors and dtors are peculiar pieces of code a class may have, just about the same as pre and post contracts for functions, or unit tests. Fourth, static constructors. "static constructor" (or "static ctor") makes more sense than "static this". </IMHO>
 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).
?? Please enlighten a Phyton ignorant... Ric
Aug 01 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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.


 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
Aug 01 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 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?)
Aug 01 2003
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
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
Aug 01 2003
next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
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");
Aug 01 2003
next sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"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.
Aug 01 2003
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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");
Aug 01 2003
parent reply Andy Friesen <andy ikagames.com> writes:
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) { ... } ... }
Aug 03 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 Why not just use static methods?
Because that would be one less thing to argue about
Aug 03 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
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) { ... } ... }
Aug 05 2003
prev sibling parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"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) }
Aug 04 2003
parent reply Benji Smith <Benji_member pathlink.com> writes:
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)
    }
Aug 04 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
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)
    }
Aug 04 2003
prev sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"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
Aug 04 2003
prev sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"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
Aug 04 2003
prev sibling parent reply Frank Wills <name host.com> writes:
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
 
 
Aug 01 2003
next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
 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
Aug 03 2003
prev sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"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
Aug 04 2003