• Russ Lewis (16/21) Jan 21 2002 gets
• Mike Wynn (20/42) Jan 21 2002 I missed the begining of this thread, so this may have been said already...
• Pavel Minayev (8/16) Jan 31 2002 Why not just put the restiction that "super() must be called in

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

I'm forking the constructor argument off into a new thread...

 Also, constructors can call each other this way - so no need to make
 a separate initialization function, a common thing in C++.

   Exactly. The downside is that it loses the strictness of  C++ as far

as
the "life" of objects is concerned, which is a good thing, even if it

gets
in the way sometimes.

This is why I think that built-in support for an Init function would be
good.  You would call constructors like C++ does, building vtable up
gradually like C++ does.  However, after the constructors complete, D
would call the (virtual) function Init.  This would allow you the to
keep the "strictness of life" of objects while still having a place
where you can call virtual functions on initialization.

Other than the overhead of potentially modifying the vtable many times,
this seems like the "best of both worlds."

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Mike Wynn" <mike.wynn l8night.co.uk> writes:

I missed the begining of this thread, so this may have been said already.
I agree with Walter and Java's designers that the vtable should be set
correctly by the new operator and not constantly changed within the
constructors.
being able to call virtual setup() from the base class constructor and have
it call a super class method is great, to do this is C++ requires virtual
base classes and all manner of fun with pointers to functions (See Borland's
TurboVision Source).

personally I believe that the D/Java constructor behaviour is the correct
one for an object orientated language.

if you realy realy require non virtual evokes of a member function in you
base class
you can always have a private init function. with a virtual member as the
public interface that calls it if the function if required after
construction.

IMHO: if you are having to perform non-virtual method calls to a base class
there is something wrong with your object heirachy or design.

Mike.

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C4C3598.C25F9106 deming-os.org...
 I'm forking the constructor argument off into a new thread...

 Also, constructors can call each other this way - so no need to make
 a separate initialization function, a common thing in C++.

   Exactly. The downside is that it loses the strictness of  C++ as far

 as
the "life" of objects is concerned, which is a good thing, even if it

 gets
in the way sometimes.

 This is why I think that built-in support for an Init function would be
 good.  You would call constructors like C++ does, building vtable up
 gradually like C++ does.  However, after the constructors complete, D
 would call the (virtual) function Init.  This would allow you the to
 keep the "strictness of life" of objects while still having a place
 where you can call virtual functions on initialization.

 Other than the overhead of potentially modifying the vtable many times,
 this seems like the "best of both worlds."

 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]

"Pavel Minayev" <evilone omen.ru> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C4C3598.C25F9106 deming-os.org...

 This is why I think that built-in support for an Init function would be
 good.  You would call constructors like C++ does, building vtable up
 gradually like C++ does.  However, after the constructors complete, D
 would call the (virtual) function Init.  This would allow you the to
 keep the "strictness of life" of objects while still having a place
 where you can call virtual functions on initialization.

 Other than the overhead of potentially modifying the vtable many times,
 this seems like the "best of both worlds."

Why not just put the restiction that "super() must be called in
the constructor"? Like the "missing return" in functions...

The problem with C++ way of calling constructors is, sometimes
you want to call it with some arguments conditionally. In C++,
this results in something like a ? b ? c ? d : e : f ... and
it might get even worse. In D, you just use a switch().