nicht angemeldet
Hi Martin
[..] Disskusion zu Clones und Clonable
, wann ist es Müll Was? Die Methode clone()? Wenn sie falsch verwendet wird (Stichworte: flaches/shallow oder tiefes/deep Kopieren). Wie man die clone()-Methode implementiert ist Sache des Entwicklers und nicht der Sprache.
Du hast aus dem Zusammenhang zitiert, ich sprach ausdrücklich nur von Klassen die zu Java gehören.
, oder das selbe mit equals das auf die Referenz und nicht auf den Inhalt vergleicht? Ich finde diese Thematik eigentlich einleuchtend. Default-Verhalten:
[..]
Das Verhalten ist mir durchaus bekannt, ich ärgere mich lediglich über die inkonsistente Implementierung innerhalb der zu Java gehörenden Klassen. Bei allen anderen Klassen geb ich dir Recht, Aufgabe des Entwicklers. Beispiel für zu Java gehörende Klassen: String und StringBuffer...
Beispiel: Bei String-Objekten (s.u.) ist die equals()-Methode derart überschrieben, dass auf inhaltliche Gleichheit geprüft wird -> "Hallo".equals("Hallo") == true.
Bei String ja, bei StringBuffer bereits wieder nicht.
Soweit finde ich das Konzept eigentlich leicht verständlich (obschon das zugrundeliegende Prinzip natürlich schwieriger zu verstehen ist als der Gebrauch einer for-Schleife). Bis auf eine Ausnahme (s.u.) finde ich es auch sehr praktikabel, da immer vorhersehbar ist, was ein "=="-Vergleich prüft. Soweit ich weiß, gibt es in den C-Derivaten (oder nur C++) auch das Konzept der Operator-Überlagerung. Dies mag einerseits größere Flexibilität mit gut lesbarer Syntax verknüpfen, dürfte aber in der Praxis auch zu Problemen führen bzw. prinzipiell den Keim zur Verwirrung in sich tragen (Stichpunkt: Erben von Klassen, zu denen der Quellcode und/oder eine entsprechende Doku fehlt).
Der == Vergleich ist keinerlei Problem, grundsätzlich ist bei c++ == vergleichbar mit .equals in Java, es tut dass, was der Entwickler der Klasse für richtig hält, wenn man auf Adressgleichheit prüfen will in C/C++, geht das nunmal anders. Mit == auf Referenzgleichheit prüfen zu wollen, ist wie mit .equals auf Referenz prüfen zu wollen, manchmal gehts, manchmal nicht.
Mit der Vererbung hast du in Java genau das selbe Problem, wenn du die Doku nicht hast, hast du keine Ahnung was .equals tut.
[..] Erklärungen wieso bei String .equals zu benutzen ist.
Kein Einspruch das .equals zu benutzen ist, nur würde ich das eben auch gerne bei StringBuffer tun und würde ein konsistentes Verhalten erwarten, irgendwie muss ich schliesslich Zeichenketten auf den Inhalt überprüfen können, egal wie die technische Implementierung aussieht.
Wir würdest Du denn das prinzipielle Problem des Unterschiedes zwischen Objekt- und Inhaltsgleichheit und deren Prüfung lösen (bzw. wie ist es denn in anderen OO-Sprachen gelöst? Eleganter? Einfacher?)
Konsistent innerhalb der Klassen die zum JDK gehören, ich habe nichts dagegen dass == auf Referenz prüft, auch nichts dagegen dass .equals auf Inhalt prüft, nur möchte ich das gerne identisch haben, wenn Inhaltsgleichheit möglich ist, dann ist irgendeine Methode implementiert die implementiert wie Inhaltsgleichheit innerhalb der Realität definiert ist, ansonsten soll die Vergleichsmöglichkeit bei Inhalt einfach fehlen, aber nicht etwas da sein, was mir suggeriert, es ginge doch.
Nein, es nimmt ihm das Nachdenken ab indem es vorgaukelt dass es das nicht wäre, das sind dann die schlecht designten Applikationen von denen du sprichst. Schliesslich schreit Java dem Anwender ja entgegen, bei mir gibt es nichts gefährliches... Meinst Du mit "gefährliches" Stolperfallen? Hat nicht jede Sprache ein Reservoir an solchen? Mir hat Java nichts entgegengeschrien und auch nichts vorgegaukelt. Ich versuche zu verstehen, was einer Sprache mir bietet, welche Dinge problematisch sind, und verwende sie entsprechend.
Mir schreit Java die ganze Zeit vor, Pointer sind gefährlich, damit kann ich Speicherlücken bauen, deswegen gibt es sie nicht, es wird gesagt Speicherlöcher seien dadurch unmöglich, jede Speicherverwaltung würde die VM tun, nur stimmt das nicht, mangels vernünftiger Destruktoren bleiben Files geöffnet wenn man sie nicht explizit schliesst. (Ich weis das Files offenlassen schlechter Stil ist).
Und Sun kann darüber entscheiden ganz alleine, ja, nette Community, aber keine Druckmöglichkeit. BTW: es passiert wohl mir nichts dir nichts, wenn zb Bugmeldungen als solved geschlossen werden, allerdings mit einer API-Änderung in der nächsten Version (Beispiel erneut URLEncoder) OK, in diesen Prozessen stecke ich zu wenig drin. Soweit mir bekannt ist, hat das W3C auch keinerlei Druckmöglichkeit auf die Umsetzung der Standards in Applikationen. Welche Organisationsform oder Intstitution böte denn Deiner Meinung nach solche Möglichkeiten? Wie ist das bei anderen Sprachen? Es ist doch letztlich immer vom Good-Will der beteiligten Entscheidungsträger abhängig, oder? Ich lasse mich aber gerne eines Besseren belehren.
Ich möchte gerne sowas wie ANSI-C++, eine Sprachbasis die festgelegt ist, auf die ich mich verlassen kann und die eine klare Versionsnummer trägt. Das ist unrealistisch, ich weis, auch bei C++ können gewisse Compiler nicht was sie sollten.
Er plädiert dafür, ältere Applikation nicht nur deswegen ändern zu müssen, weil irgend ein Hersteller lust hat, alte APIs nicht mehr zu unterstützen. Wieso muss er das? Die "alte" Laufzeit-Umgebung existiert doch weiterhin? Und da jede Applikation per default sowieso in ihrer eigenen VM läuft (und auch sollte), sehe ich da auch überhaupt kein Problem.
Und was tut ein Benutzer der Applikationen hat die eine neue VM benutzen? Das es möglich ist, verschiedene VMs zur selben Zeit laufenzulassen wäre mir nicht bewusst, ich lasse mich da aber gerne aufklären.
Und ganz genau das heist deprecated, Vorsicht, ändere es, irgendwann unterstützen wirs einfach nicht mehr. Für mich ist ein API ein Standard, und ein solcher wird weiterentwickelt wie viele andere auch. Dies bedeutet aber auch, dass man Fehlerhaftes korrigiert und Ungeeignetes/Gefährliches entfernt. Wie stehst Du denn zu deprecated-Deklarationen verschiedener HTML-Tags durch das W3C?
Ganz grundsätzlich halte ich das für ein Problem wenn deswegen diese Tags bei ensprechender DOCTYPE Deklaration nichtmehr unterstützt würden, nur sind für mich HTML-Seiten kurzlebiger als Applikationen (Ich hab schon 20 jährige Applikationen anpassen müssen). Zudem steckt in den meisten Fällen nicht ganz so viel Arbeit drin. (10 Personenjahre und mehr sind wohl eher unwahrscheinlich für eine einzige Version). Dazu kommt, das wohl die Anpassungen einfacher sind und weniger Auswirkungen rundherum haben. Auch sind die Auswirkungen wohl weniger gravierend, hauptsächlich sind Formatierungstags weggefallen, dann sieht schlimmstenfalls etwas nicht mehr gut (oder auch grässlich) aus aber die Seite verweigert nicht vollständig ihren Dienst.
Die Sprache Java ist sehr schwach, Das ist mir zu banal. Was meinst Du mit "schwach"?
Die Sprache Java besteht aus einem Haufen Schlüsselwörter, die können grundsätzlich mal nicht sehr viel, wozu auch, dafür gibt es die Klassenbibliothek. Ich finde das auch auf keine Fall negativ sondern eher positiv, nur ist es eben nicht die Sprache die viele Dinge von Haus aus kann.
die Klassenbibliothek Java ist stärker, gehört jedoch nicht zu einer Sprache, und Java lässt sowohl in der Klassenbibliothek, als auch in der Sprache sehr elementare Dinge vermissen, so zum Beispiel für eine Sprache sie sich wunderbar Objektorientiert nennt Design by Contract. Kannst Du das Prinzip kurz erläutern? Von welchen OO-Sprachen wird das untertützt?
Nehmen wir an, ein Parameter darf nur Werte zwischen 2 und 5 annehmen, das einzige was du tun kannst, ist in nem anderen Fall eine Exception zu werfen, oder sonst irgend etwas nettes wie Fehlermeldung in die Konsole zu schreiben.
Bei Design by Contract sagst du hingegen bei diesem Parameter, er darf nur diese Werte annehmen, und das musst du dann auch nicht mehr händisch überprüfen. Die einzige Sprache die mir bekannt ist die das macht ist Eiffel (leider sehr teuer und kaum verbreitet).
Was sind weitere Beispiele, die die Verwendung des Plurals "elementare Dinge" rechtfertigen?
Templates, ein Haufen anderer schöner Dinge die UML kann, Java aber nicht (C++ zu nem grossen Teil auch nicht). Dann die Existenz von primitiven Datentypen, vorallem im Zusammenhang mit den Collections ist das mühsam und fehlerträchtig.
Java ist kein sauberes OO, Nun ja, ich sehe das weniger puristisch oder akademisch. Ich halte es für gut praktizierbares OO.
Ich halte es auch für praktizierbares OO wenn es keine Basisdatentypen gibt. Genauergesagt würde ich das für sehr viel bequemer halten. Performanceentscheide halte ich in dem Zusammenhang für falsch da diese eher in den Optimierer des Compilers gehören und nicht dem Benutzer aufgebrummt werden sollten.
und es ist auch bei ernsthaftem und dauerhaftem Beschäftigen nicht angenehmer mit Java zu arbeiten. Das kann ich für Dich leider nicht widerlegen.
Stimmt, weil, das ist wie mit allen Programmiersprache reine Geschmackssache.
Speicherlöcher krieg ich dir in Java auch ohne Pointer hin. Was meinst Du mit "Speicherloch"?
Unnötig verwendeter Speicher der zur Laufzeit nicht mehr benutzt werden kann und auch nichts sinnvolles mehr enthält, also sozusagen verschwendeter Speicher. Das passiert wenn man Files nicht explizit schliesst und alle Referenzen auf das Objekt verliert.
Und Designfehler in anderen Klassen machen diesen Vorteil zumindest für Servlets bis und mit Java 1.3.1 zunichte -> URLEncoder (mein persönlicher Liebling) Mit diesem Encoder sollte ich mich mal beschäftigen. Was ist eigentlich Euer konkretes Problem damit?
Das Problem ist eher ein Designfehler unsererseits in dem Fall, kann aber auch sehr gut auftreten wenn der Designfehler nicht vorliegt. URLs werden ja bei der Übertragung URLEncoded (gibt n RFC dafür, hab ich nicht zur Hand), jetzt haben aber einige der Zeichen die verschlüsselt werden müssen andere Positionen im Zeichensatz je nach verwendetem Zeichensatz. Da unsere Benutzer auf der ganzen Welt sind, sind die Zeichensätze entsprechend vielschichtig genauso wie die Laute die verschlüsselt werden müssen (da ist unser Designfehler die nicht HTMLmässig zu verschlüsseln, passiert jedoch auch mit normaleren Sonderzeichen). Jetzt gibt es aber keinerlei Möglichkeit (in Java 1.4 gibt es sie) den Zeichensatz zu spezifizieren der verwendet werden soll, es wird auch nicht der benutzt, der im Webserver eingestellt ist, sondern der, des Servers (also Hardware/Betriebssystem).
Und Umsteigen auf die neue Javaversion ist in unserem Fall im Moment nicht möglich.
- Java ist Binärcode-kompatibel Was soll das sein? Verklausuliert für plattformunabhängig ;-))
ANSI C ist auch Plattformunabhängig, muss nur immer wieder compiliert werden. Zudem hat Java da meiner Meinung nach mit Swing viel verloren, und zwar weil es eben nicht ein Button so macht wie ich ihn mir gewohnt bin, sondern wie der Progammierer es will. Auf die das ich meine Oberfläche und meine Einstellung wie alles aussehen soll aber sehr bewusst ausgewählt habe, kommt kein Programmierer. Jetzt läuft die Applikation zwar noch auf allen Plattformen (für die es VM's gibt), aber es sieht nicht mehr aus wie eine normale Applikation für diese Plattform. Mit AWT tut es das allerdings nach wie vor.
Gruss Daniela