staging.inyokaproject.org

Ist das nicht die gleiche Diskussion wie beim Goto? Es stellt sich doch die Frage, was Sprachfeatures sollen, deren Verwendung im Allgemeinen zum schlechten Code führen. Klar ist ihre versehentliche Verwendung ausgeschlossen, aber aus ihrer Existenz folgt auch zwangsläufig ihr Einsatz. Der Vorteil von Java, für Firmen die ihren Code für lange Zeit und von den Entwicklern die ihn produzierten unabhängig warten müssen, ist doch gerade, dass sie eine Garantie haben, dass solche Features nicht benutzt werden.

@phst: Was meinst Du damit, dass Python keinen richtigen Unicode-Support in der Standardbibliothek hat!? Es gibt einen eigenen Typ unicode, das codings-Modul um Dateiobjekte in Filter zu "wrappen", und unicodedata für Normalisierungen, Abfragen der Kategorie oder Namen der Zeichen usw. – was fehlt denn Deiner Meinung nach noch?

@Hello World: Ich bin auch kein Fan auf OOP "auf Teufel komm raus" oder noch schlimmer, Sprachen die einen zwingen alles in Klassen zu stecken. Das ist eben nicht immer sinnvoll. Auf der anderen Seite gibt's Sprachen mit dem Motto "alles ist Objekt", die einem trotzdem nicht für alles einen OOP-Stil aufzwingen. Je mehr man sich dem ursprünglichen OO-Modell nähert, dass ein Programm aus Objekten besteht, die über Nachrichten miteinander kommunizieren, und zum Beispiel Klassen ganz weg lässt, umso mehr kann man sich interessanterweise einem funktionalen Programmierstil annähern. Siehe zum Beispiel die Sprache Io, wo sogar die Kontrollstrukturen wie if oder Schleifen als Methoden auf Objekten implementiert sind. Da bekommt man schnell ein "Lisp feeling".

@Kinch: Also GOTO ist gut! Muss gut sein, weil Python ja auch supertoll ist, und für Python gibt's ein goto-Modul. Und nicht nur dass, das Modul enthält auch ein comefrom, also sozusagen das Gegenteil von GOTO – man gibt nicht an wohin gesprungen werden soll, sondern beim Ziel von wo aus dort hingesprungen werden soll. So etwas habe ich bei BASIC früher immer vermisst. ☺

Bei Python ist Mehrfachvererbung möglich, aber man sieht sie selten im Einsatz, und wenn dann fast immer als Mixin-Klassen. Und auch so Sachen wie Metaklassen werden nicht ständig verwendet.

Kinch schrieb:

Klar ist ihre versehentliche Verwendung ausgeschlossen, aber aus ihrer Existenz folgt auch Zwangsläufig ihr Einsatz.

Im Falle von Mehrfachvererbung und Python ist dieser Schluss falsch. Man muss schon lange suchen, um Mehrfachvererbung in Python zu finden, während man in Javas Standardbibliothek keine zwei Sekunden braucht, um das erste Interface zu finden. Im Vergleich zu Javas Vererbungshierarchien ist Python gerade zu putzig.

Kinch schrieb:

Ist das nicht die gleiche Diskussion wie beim Goto? Es stellt sich doch die Frage, was Sprachfeatures sollen, deren Verwendung im Allgemeinen zum schlechten Code führen. Klar ist ihre versehentliche Verwendung ausgeschlossen, aber aus ihrer Existenz folgt auch zwangsläufig ihr Einsatz. Der Vorteil von Java, für Firmen die ihren Code für lange Zeit und von den Entwicklern die ihn produzierten unabhängig warten müssen, ist doch gerade, dass sie eine Garantie haben, dass solche Features nicht benutzt werden.

Grady Booch (Miterfinder der UML) hat mal gesagt: "Multiple inheritance is like a parachute; you don't need it very often, but when you do it's essential". Man kann sein Design mit oder ohne Mehrfachvererbung versauen. Das ist aber kein Grund, diese nicht zu erlauben, denn manchmal stellt sie einfach die eleganteste Lösung für ein Problem dar.

Wo kämen wir denn hin, wenn alles, womit man Mist bauen kann, verboten würde? Keine while-Schleifen mehr, weil man ja Endlosschleifen bauen kann?

Hello World schrieb:

Das ist ein haarsträubender Vergleich. Die Entscheidung, Mehrfachvererbung zu nutzen, muss vom Entwickler explizit getroffen und umgesetzt werden. Ein Handwerker wird dagegen kaum bewusst die Entscheidung treffen, sich jetzt mal ein einen Finger abzusägen. Und wenn er das doch tut, dann kann man wohl wirklich sagen, dass er selbst schuld ist.

Wie der Handwerker wird der Entwickler auch kaum bewusst die Entscheidung treffen, Mehrfachvererbung falsch einzusetzen. Und wenn er das doch tut, ist nicht der Entwickler der Leittragende, sondern der, der die Software einsetzt. Aus diesem Grunde halte ich gewisse Schutzmechanismen für essentiell, besonders wenn Dritte dadurch zu Schaden kommen können.

Lunar schrieb:

Man muss schon lange suchen, um Mehrfachvererbung in Python zu finden, während man in Javas Standardbibliothek keine zwei Sekunden braucht, um das erste Interface zu finden. Im Vergleich zu Javas Vererbungshierarchien ist Python gerade zu putzig.

Vorsicht, die Implementierung mehrerer Interfaces ist keine Mehrfachvererbung. Es ist mit Interfaces unmöglich, die Probleme der Mehrfachvererbung umzusetzen, siehe folgenden Pseudocode:

class KlasseA {
  print() { 
    gebeAus("Hello World");
  }
}
class KlasseB {
  print() {
    gebeAus("Hello Lunar");
  }
}
class KlasseC extends KlasseA, KlasseB { }

Was gibt KlasseC aus, wenn ich klasseC.print() aufrufe, "Hello World" oder "Hello Lunar"?

ryiden schrieb:

Hello World schrieb:

Das ist ein haarsträubender Vergleich. Die Entscheidung, Mehrfachvererbung zu nutzen, muss vom Entwickler explizit getroffen und umgesetzt werden. Ein Handwerker wird dagegen kaum bewusst die Entscheidung treffen, sich jetzt mal ein einen Finger abzusägen. Und wenn er das doch tut, dann kann man wohl wirklich sagen, dass er selbst schuld ist.

Wie der Handwerker wird der Entwickler auch kaum bewusst die Entscheidung treffen, Mehrfachvererbung falsch einzusetzen. Und wenn er das doch tut, ist nicht der Entwickler der Leittragende, sondern der, der die Software einsetzt. Aus diesem Grunde halte ich gewisse Schutzmechanismen für essentiell, besonders wenn Dritte dadurch zu Schaden kommen können.

Ämmm wenn ein entwickler absichtichlich schlechte Software entwickeln möchte schafft der das. Egal mit welcher Sprache!

ryiden schrieb:

Was gibt KlasseC aus, wenn ich klasseC.print() aufrufe, "Hello World" oder "Hello Lunar"?

Probier’s doch aus ☺

Wenn man von der Absicht ausgeht, dann trifft das durchaus zu.

Wenn ich etwas bewusst tue (wie du schreibst) ist das dann nicht absichtlich?!

Dirk Sohler

Probier’s doch aus

Das könnte ich tun, aber dann würde ich nur ein Compiler-Abhängiges Ergebnis feststellen. CompilerA entscheidet sich für die print-Methode aus KlasseA, CompilerB für die print-Methode aus KlasseB und CompilerC bemerkt das Problem und gibt einen Fehler aus.

Nilres schrieb:

Wenn ich etwas bewusst tue (wie du schreibst) ist das dann nicht absichtlich?!

Ich habe kaum bewusst geschrieben, das ist genau das Gegenteil 😉

ryiden schrieb:

Vorsicht, die Implementierung mehrerer Interfaces ist keine Mehrfachvererbung. Es ist mit Interfaces unmöglich, die Probleme der Mehrfachvererbung umzusetzen, siehe folgenden Pseudocode:

class KlasseA {
  print() { 
    gebeAus("Hello World");
  }
}
class KlasseB {
  print() {
    gebeAus("Hello Lunar");
  }
}
class KlasseC extends KlasseA, KlasseB { }

Was gibt KlasseC aus, wenn ich klasseC.print() aufrufe, "Hello World" oder "Hello Lunar"?

Bei solchen Fragen mit Pseudocode anzukommen ist ziemlich sinnlos, da solche Sachen eben in erheblichem Maße davon abhängen, wie das in der jeweiligen Sprache geregelt ist. In C++ lässt sich so etwas gar nicht übersetzen, und das ist nicht compilerspezifisch, sondern im Standard festgelegt.

mi.cc:17: error: request for member ‘print’ is ambiguous
mi.cc:8: error: candidates are: void KlasseB::print()
mi.cc:3: error:                 void KlasseA::print()

Hello World

In C++ lässt sich so etwas gar nicht übersetzen, und das ist nicht compilerspezifisch, sondern im Standard festgelegt.

Falsch, mit Deinem C++-Compiler lässt sich so etwas nicht übersetzen. Ich zitiere mich an dieser Stelle mal selbst:

Das könnte ich tun, aber dann würde ich nur ein Compiler-Abhängiges Ergebnis feststellen. CompilerA entscheidet sich für die print-Methode aus KlasseA, CompilerB für die print-Methode aus KlasseB und CompilerC bemerkt das Problem und gibt einen Fehler aus.

Als ich damals mit meiner Ausbildung angefangen hatte, wurden solche Fehler vom C++-Compiler noch nicht bemerkt. Kannst Du mal die Stelle im Standard posten, in der das festgelegt ist? Es kann zwar sein, dass ältere C++-Compiler solche Standards noch nicht vollständig umgesetzt haben, aber ich würde das gerne mal vergleichen.

EDIT: Hat sich erledigt, die Sprachnorm gibt es erst seit 1998 und es hat wohl mehrere Jahre gedauert, bis alles umgesetzt wurde.

ryiden schrieb:

Wie der Handwerker wird der Entwickler auch kaum bewusst die Entscheidung treffen, Mehrfachvererbung falsch einzusetzen. Und wenn er das doch tut, ist nicht der Entwickler der Leittragende, sondern der, der die Software einsetzt. Aus diesem Grunde halte ich gewisse Schutzmechanismen für essentiell, besonders wenn Dritte dadurch zu Schaden kommen können.

Wöde ich mal so verstehen das du das gegenteil von kaum bewusst meinst ⇒ bewusst ⇒ absicht.

Ein Synonym für kaum ist sehr wenig, somit ist kaum bewusst = unbewusst.