一部で下位互換と上位互換が混同されていますが、ここでは、上位版は下位版の機能を保証するという意味です。
ネタ元
ここここで、 C++ はCの柵の影響で汚れている云々の話が出てきます。
#主題のAccess修飾子に関しては、現状で充分と考えてます(本音は、論じるほどの知識がないので....orz)
私は一時期、C++を構文チェックの厳しいCという認識で使っていた時季が有ります。それはそれで、効率アップしたと思います。
さて、C++は下位互換性があると言い切れるか。....環境依存性が大きいですね。(Windows依存の部分がないとして) UNIX環境のC/C++ソースがそのまま、Windowsで動くか。 68系のCompilerと 86系のコンパイラ、 の差。
同じインテル系でも、DOS時代の 64Kbyte制約による Compile Modeの組みあわせ等、とても下位互換性100%とは言えません。もっとも、これには、言語仕様と環境仕様が混在するので、単純な問題ではないのですが。
他方、汎用機の世界は 100%の下位互換性が求められます。30年前に作成した、Exeはそのまま走るし、そのままで、Compileできることが求められます。
どちらが良い悪いの問題でなく、システムに求められる要求度の違いです。汎用機は、新機能の取り入れよりも安定をも求められます。
オープン系は、過去の不細工になった部分は、切り捨てることで、脱皮して発達してきました。いまだに、「下位互換のないオープン系は信用できない」と言われる所です。
言語の下位互換を捨てることで、脱皮できました、 VBなど、旧VBから脱皮したから、.net化できました。もっと切り捨てて欲しかった文法は多いですが...
JAVAの世界も似たようなものでしょう。
進歩と過去のしがらみの共存は、難しいものです。どちらをとっても、非難者は出てきます。
話が飛ぶようですが、ヨーロッパは過去の遺物の風体を残すため、新築でも、元の外見に似せる必要があるそうです。
東京みたいに、無秩序な開発はできないそうです。
奈良地方では、開発に着手したら、古跡が見つかり開発中断に落ちいることが多いとか。過去を大事にするために、発展の速度を犠牲にするとの是非はんとも言えません。相容れるものではなさそうです。
文化や伝統の維持運動をを「後ろ向き運動」と捉える人もいるくらいです。人の意見の多様性を感じた次第です。
#私は、古きモノでも、不合理箇所は変更すべきとする派です。過去を大事にしないと言われますが...orz;