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

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

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