In Java 1.4.2 gibt es doch noch gar keine Generizität? Das wurde erst mit 1.5 (oder 5.0, wie es auch heißt) eingeführt.
Zitat von jimbeamMir kommt aber vor das wir in der Schule auch mit JDK1.4.2 programmiert haben! Und da hat es funktioniert!
Es gab für die älteren Java-Versionen verschiedene generische Erweiterungen. Aber die sind nun alle obsolet.
JDK 1.4 ist an sich schon obsolet 
Und die Generizität in 1.5 ist einfach nur krank, schwach und nicht typsicher. Nur damit sie die VM nicht ändern mussten, ist eine List<Person> dasselbe wie eine List<Auto>, weil die Übersetzung homogen ist (Übersetzung in die Klasse List, die statt dem generischen Parameter einfach "Object" einsetzt).
Naja, das passiert, wenn ein paar Tunnelblick-C++-Programmierer daherkommen und glauben, dass man in jeder Sprache Generizität haben muss, weil das in C++ ja auch absolut notwendig ist.
(Und in C++ ist es wirklich so, dass man ohne Generizität nicht programmieren kann, ohne sehr abenteuerliche Casts zu machen, was in dynamischen Programmiersprachen wie Java oder Objective C kein Problem ist, nachdem der Typ dann sowieso zur Laufzeit kontrolliert wird.)
Zitat von halwas in dynamischen Programmiersprachen wie Java oder Objective C kein Problem ist, nachdem der Typ dann sowieso zur Laufzeit kontrolliert wird
... verstehe ich nicht ...
man kann in c++ mit einem dynamic_cast doch auch zur laufzeit kontrollieren!?
obj. c kenne ich nicht (außer vom namen), aber ich erkenne in javas "instaceof" (was du wohl mit "zu laufzeit kontrollieren" meinst) keinen vorteil/unterschied zu einem dynamischen cast in c++ ...
Und die Generizität in 1.5 ist einfach nur krank, schwach und nicht typsicher. Nur damit sie die VM nicht ändern mussten, ist eine List<Person> dasselbe wie eine List<Auto>, weil die Übersetzung homogen ist (Übersetzung in die Klasse List, die statt dem generischen Parameter einfach "Object" einsetzt).
Vollste Zustimmung.
Frage: Ist diese schwache Pseudo-Generizität besser als gar keine ???
(Bin mir da nicht sicher)
Wenn du in Java (bla)meinvektor.elementAt(4711) machst und das Objekt ist kein bla, dann bekommst du eine Exception. In C++ stürzt das Programm früher oder später komplett ab. dynamic_cast<> kann helfen, aber das verwenden C++-Programmierer nicht, nachdem das alle Vorteile von C++ übern Haufen wirft.
In Objective C kommt der Dynamismus viel mehr durch. Dort ist es völlig egal, von welcher Klasse ein Objekt abgeleitet wurde, hauptsache es implementiert die Methoden, die man verwendet. Das geht in Java auch via Reflection, allerdings ist es dort etwas mühsamer zu verwenden.
Zitat von Lord BinaryFrage: Ist diese schwache Pseudo-Generizität besser als gar keine ???
(Bin mir da nicht sicher)
Solange man es nicht verwendet, ist es wenigstens nur genau so schlimm wie keine zu haben
Zitat von halNaja, das passiert, wenn ein paar Tunnelblick-C++-Programmierer daherkommen und glauben, dass man in jeder Sprache Generizität haben muss, weil das in C++ ja auch absolut notwendig ist.
Aber es ist auch tatsächlich notwendig. Hauptsächlich für die Implementierung homogener Collections (Listen, Arrays, ...). Object stattdessen zu verwenden ist dann ein Problem, wenn du aus der jeweiligen Collection wieder was rausnehmen willst, weil du dann zwingend einen Cast brauchst und der ist in Java nicht typsicher (man kann schließlich alles in eine Collection stecken, das von Object erbt).
In C++ hat man das "Problem", dass es keine oberste Klasse in der Vererbungshierarchie gibt (ein void* wäre so was, aber auch nur für Zeiger "Person* p", nicht für z.b. "Person p"). Daher _kann_ man Generizität überhaupt nur so erreichen, wie es gemacht wurde.
Zitat von Lord BinaryVollste Zustimmung.
Frage: Ist diese schwache Pseudo-Generizität besser als gar keine ???
(Bin mir da nicht sicher)
Es ist definitiv schon mal eine Verbesserung, weil damit zumindest der Typecast beim Rausholen eines Elements aus einer Collection auf der Seite des Programmierers wegfällt.
Besser wäre es aber gewesen, die JVM zu updaten und damit echte, typsichere Generizität zu erlauben. Bei C# gibt es daher den Sprung von 1.1 auf 2.0.
Aber was ich mich überhaupt frage: Warum hat man nicht Generizität gleich von Anfang an in den beiden Sprachen berücksichtigt? Es war sowieso klar, dass die früher oder später kommen muss (alle ernsthaften statischen OO Sprachen hatten davor schon Generizität (C++ und Eiffel fallen mir ein), dynamische brauchen es ja nicht). Man hätte es ja nicht gleich aktivieren müssen, aber zumindest im Code-Layout vorsehen, dass es das mal geben wird.
EDIT: Einen Punkt hab ich noch vergessen: Bessere Lesbarkeit.
Zitat von sauzachnEs ist definitiv schon mal eine Verbesserung, weil damit zumindest der Typecast beim Rausholen eines Elements aus einer Collection auf der Seite des Programmierers wegfällt.
Auf der anderen Seite kann man so nimmer verschiedene Objekte mischen in einem Array.
Besser wäre es aber gewesen, die JVM zu updaten und damit echte, typsichere Generizität zu erlauben. Bei C# gibt es daher den Sprung von 1.1 auf 2.0.
Damit würden aber vermutlich alte Java-Apps nimmer in der neuen VM laufen.
Aber was ich mich überhaupt frage: Warum hat man nicht Generizität gleich von Anfang an in den beiden Sprachen berücksichtigt? Es war sowieso klar, dass die früher oder später kommen muss (alle ernsthaften statischen OO Sprachen hatten davor schon Generizität (C++ und Eiffel fallen mir ein), dynamische brauchen es ja nicht).
Du hast dir deine Frage selber beantwortet. Java ist eine dynamische Programmiersprache. Dass der Syntax C++ so ähnlich sieht sollte einen da nicht in die Irre führen.
Vermutlich war die Entscheidung, die Dynamik von Java so zu verstecken eine, die das Marketing gemacht hat, und nicht die Sprachdesigner.
EDIT: Einen Punkt hab ich noch vergessen: Bessere Lesbarkeit.
Du hast offensichtlich noch nie eine C++-Compilerfehlermeldung gesehen
Zitat von halAuf der anderen Seite kann man so nimmer verschiedene Objekte mischen in einem Array.
Das soll man aber eh nicht tun. Ein Array ist eine Sammlung von Objekten vom gleichen (Basis-)Typ.
Zitat von hal
Damit würden aber vermutlich alte Java-Apps nimmer in der neuen VM laufen.
Ja, das stimmt natürlich. Aber ein JVM Update wäre wohl nicht wirklich schwierig durchzusetzen gewesen. Bei C# funktionierts ja auch.
Zitat von hal
Du hast dir deine Frage selber beantwortet. Java ist eine dynamische Programmiersprache. Dass der Syntax C++ so ähnlich sieht sollte einen da nicht in die Irre führen.
Vermutlich war die Entscheidung, die Dynamik von Java so zu verstecken eine, die das Marketing gemacht hat, und nicht die Sprachdesigner.
Hm. Die Dynamik ist in der Tat sehr versteckt. Nach klassischer Definition halte ich Java für keine dynamische Sprache. Jedenfalls nicht in der Liga von Smalltalk. Java ist viel zu stark typisiert für eine echte dynamische Sprache. Auch noch viele andere Dinge werden statisch überprüft (ob es bestimmte Methoden gibt, welche Argumente die übernehmen usw.).
Zitat von halDu hast offensichtlich noch nie eine C++-Compilerfehlermeldung gesehen
Leider viel zu viele Vor allem im Zusammenspiel mit Boost tut jede einzelne Template-Fehlermeldung körperlich und geistig weh.
Zitat von sauzachnDas soll man aber eh nicht tun. Ein Array ist eine Sammlung von Objekten vom gleichen (Basis-)Typ.
Ja, java.lang.Object
Verschiedene Objekte in ein Array reinzustecken kann recht praktisch sein, wenn man zB ein struct ersetzen will.
Ja, das stimmt natürlich. Aber ein JVM Update wäre wohl nicht wirklich schwierig durchzusetzen gewesen. Bei C# funktionierts ja auch.
C# verwendet auch noch kein Schwein. Bei Java gibts eine viel zu große installed user base. Ist schon schwer genug, so auf 1.5 umzusteigen (mein Hoster hat zB immer noch 1.4.2 laufen, 1.5 ist in gentoo immer noch unstable, etc).
Hm. Die Dynamik ist in der Tat sehr versteckt. Nach klassischer Definition halte ich Java für keine dynamische Sprache. Jedenfalls nicht in der Liga von Smalltalk. Java ist viel zu stark typisiert für eine echte dynamische Sprache. Auch noch viele andere Dinge werden statisch überprüft (ob es bestimmte Methoden gibt, welche Argumente die übernehmen usw.).
Es wird zwar geprüft, aber das ist nur zur einfacheren Fehlersuche für den Programmierer, man muss nicht. Mit reflection kann man zur Laufzeit rausfinden, welche Methoden ein Objekt hat, welche Parameter diese haben, und diese dann auch aufrufen. Das ist in C++ undenkbar, da kannst du eine Methode gar nicht aufrufen, wenn du nicht genau über sie bescheid weißt zur Compilezeit.
Es ist definitiv schon mal eine Verbesserung, weil damit zumindest der Typecast beim Rausholen eines Elements aus einer Collection auf der Seite des Programmierers wegfällt.
Naja, also das würd ich nicht unbedingt als DEN mörderischen Vorteil bezeichnen ...
Selbst wenn man täglich tausende dieser lästigen klassischen collection-iterator-loops mit typecasts schreibt ...
dürfte die Zeitersparnis im Sekundenbereich liegen 
Das Argument mit der besseren Lesbarkeit ist allerdings ein Gutes
Zitat von hal
Verschiedene Objekte in ein Array reinzustecken kann recht praktisch sein, wenn man zB ein struct ersetzen will.
:confused: Verstehe ich nicht ganz. Wenn ich ein C-struct ersetzen will, dann mach ich mir eine eigene Klasse mit den verschiedenen benötigten Datentypen als Klassenvariablen und fertig.
Die Java-Generizität-Diskussion hab ich doch schon mal irgendwo im Forum gelesen .... 
, der gute sauzachn wird da immer so leidenschaftlich :devil:
Zitat von Lord BinaryNaja, also das würd ich nicht unbedingt als DEN mörderischen Vorteil bezeichnen ...
Selbst wenn man täglich tausende dieser lästigen klassischen collection-iterator-loops mit typecasts schreibt ...
dürfte die Zeitersparnis im Sekundenbereich liegen
Ich meinte keinen Geschwindigkeitsvorteil bei der Ausführung, der ist sowieso nicht vorhanden (der Compiler macht dasselbe, was der Programmierer machen müsste). Ich meine den Zeitvorteil beim Schreiben! Der ist schon erheblich, wenn man Generizität viel einsetzt.
Zitat von klausi:confused: Verstehe ich nicht ganz. Wenn ich ein C-struct ersetzen will, dann mach ich mir eine eigene Klasse mit den verschiedenen benötigten Datentypen als Klassenvariablen und fertig.
Warum als Klassenvariablen? Instanzvariablen entsprechen eher einem Struct. Und in C++ unterscheiden sich Structs und Klassen - abgesehen vom Default-Zugriffsschutz - überhaupt nicht voneinander. Das ist ein Hinweis an den Java-Array-Mißbraucher Wenn es schon keine Klasse sein soll, dann wenigstens ein Set oder so was. Bitte! Wofür gibt es denn Algodat, wenn man dann so was macht
Zitat von klausi
der gute sauzachn wird da immer so leidenschaftlich :devil:
Wenn man einmal das Paradies (Eiffel) gesehen hat, will man nicht mehr zurück auf die Erde.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
