• Riccardo De Agostini (13/13) Jul 31 2003 I know I am going against an already well-established standard... but it
• Patrick Down (4/17) Jul 31 2003 Here, here! I've wanted to say the same thing for a long time but
• Burton Radons (3/9) Jul 31 2003 The benefit of this and ~this over a name is that it doesn't take any
• Riccardo De Agostini (7/9) Jul 31 2003 You're of course right. My personal opinion, though, is that the advanta...
• Ant (2/15) Jul 31 2003
• Frank Wills (10/35) Jul 31 2003 For what it's worth, this() and ~this()
• Riccardo De Agostini (14/23) Jul 31 2003 I think you're very right as to the meaning of "this": it is a placehode...
• BenjiSmith (20/43) Aug 01 2003 This has been my opinion for ages, though I haven't publicly expressed i...
• Riccardo De Agostini (18/28) Aug 04 2003 Couldn't have been better said IMHO. Maybe, just because they are method...
• Riccardo De Agostini (6/7) Jul 31 2003 Great when typing; maybe a bit confusing when having a quick look at sou...
• Matthew Wilson (11/24) Aug 01 2003 If this and ~this have to go, and I can see the point (mixing the implic...
• Riccardo De Agostini (20/26) Aug 01 2003
• Sean L. Palmer (18/47) Aug 01 2003 Calling them after the class causes lots and lots of trouble. Consider ...
• Matthew Wilson (9/12) Aug 01 2003 Yes, I agree. (You'd think STLSoft-man would have had that thought, no?)
• Mike Wynn (28/40) Aug 01 2003 I see nothing wrong with "this"/"~this"
• Burton Radons (15/18) Aug 01 2003 Ooh yes let's have that. I use subclassing for constructor separation,
• Mike Wynn (5/23) Aug 01 2003 for consistance shouldn't
• Sean L. Palmer (21/39) Aug 01 2003 Yeah I hate the way it has to be done in C++ using overloading:
• Andy Friesen (7/32) Aug 03 2003 Why not just use static methods?
• Matthew Wilson (1/2) Aug 03 2003 Because that would be one less thing to argue about
• Sean L. Palmer (9/41) Aug 05 2003 Well, it's not a direct translation. ;)
• Riccardo De Agostini (12/22) Aug 04 2003 Quite sexy indeed. But I think the following is Kamasutra :-)
• Benji Smith (3/12) Aug 04 2003 That's _really_ nice.
• Matthew Wilson (4/19) Aug 04 2003 I like this also
• Riccardo De Agostini (7/10) Aug 04 2003 I do, but that's no news. :-)
• Riccardo De Agostini (12/19) Aug 04 2003 I'd stick to this one, possibly replacing the two keywords as per other
• Frank Wills (9/27) Aug 01 2003 I like the universal simplicity of "this()" and
• Charles Sanders (6/37) Aug 03 2003 Agreed.
• Riccardo De Agostini (10/18) Aug 04 2003 I do too. I often have a brief look at code I haven't been touching for

"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

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.

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.

"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

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

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

 
 
 

"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

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

"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

"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

"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

"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

"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

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

"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

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

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

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

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

"Matthew Wilson" <matthew stlsoft.org> writes:

 Why not just use static methods?

Because that would be one less thing to argue about

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

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

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

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

"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

"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

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
 
 

"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

"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