Message from discussion OOP / language design question
From: "Diez B. Roggisch" <de...@nospam.web.de>
Subject: Re: OOP / language design question
Date: Tue, 25 Apr 2006 13:19:41 +0200
References: <firstname.lastname@example.org> <4b6ctpF109k7eU1@uni-berlin.de> <email@example.com>
Content-Type: text/plain; charset=us-ascii
X-Trace: news.uni-berlin.de HRV1YrzjgwstBR/CrwkQeA4pH/RblTaaI0yW3S0FkcTg==
> Well, I can imagine it's done to make sure that the base(s) are
> properly constructed. Sound s sensible to me.
It often is - there are popular examples in python where missing a
constructor will cause a program to fail spectacular. But is it _always_ a
sensible thing to do? No. If you only want some code inherited, but set up
the required constraints to do so yourself. Such things can't be expressed
in C++/JAVA, but that doesn't mean they aren't the sensible solution in
>> No way to do some computing for parameters that I want to pass
>> to the parent constructor...
> Try this:
> Derived::Dreived() : Base(calcParam1(), calcParam2())
Oh, I know about that. however, there are limits to this. For example, you
can't do anything that depends on constructors called before in case of
multiple inheritance. And you are forced to create a static method to do
so, which can be viewed as ugly as well.
> Well, the language can at least ensure that theconstructor is called -
> i.e. either call it automatically if it can be called without
> parameters, or fail with error.
Yes, it can do that because of static typing - in fact it will fail on a lot
more of occasions with a compilation error.
The question here is if you are willing to trade freedom of expressiveness
against the proposed security of static typing. I found that I favor the
former and can live without the latter.