Jump to page: 1 2 3
Thread overview
this
Jul 31, 2003
Patrick Down
Jul 31, 2003
Burton Radons
Jul 31, 2003
Ant
Jul 31, 2003
Frank Wills
Re: this [using "constructor" and "destructor"]
Aug 01, 2003
BenjiSmith
Aug 01, 2003
Matthew Wilson
Aug 01, 2003
Sean L. Palmer
Aug 01, 2003
Matthew Wilson
Aug 01, 2003
Mike Wynn
Aug 01, 2003
Burton Radons
Aug 01, 2003
Mike Wynn
Aug 02, 2003
Sean L. Palmer
Aug 04, 2003
Andy Friesen
Aug 04, 2003
Matthew Wilson
Aug 05, 2003
Sean L. Palmer
Aug 04, 2003
Benji Smith
Aug 04, 2003
Matthew Wilson
Aug 01, 2003
Frank Wills
Aug 03, 2003
Charles Sanders
July 31, 2003
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


July 31, 2003
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.





July 31, 2003
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.

July 31, 2003
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
>
>


July 31, 2003
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
>>
>>
> 
> 
> 

August 01, 2003
"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


August 01, 2003
"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


August 01, 2003
"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


August 01, 2003
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
>
>


August 01, 2003
"Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bgd666$2tu2$1@digitaldaemon.com...
> Why not just go along with most other languages I can think of (C++, C#, 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


« First   ‹ Prev
1 2 3