www.digitalmars.com         C & C++   DMDScript  

D - Init function?

reply 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))) ]
Jan 21 2002
next sibling parent "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))) ]
Jan 21 2002
prev sibling parent "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().
Jan 31 2002