Hi ,
ich frage den Wert eines Textfeldes ab.
Wenn nichts drinsteht, soll laut doku JDK 1.2.2 ein leerer String ("") zurückgegebn werden.
Diesen frage ich mit
if( MeinString==""||MeinString==null)
ab.
Leider klappt das nicht!
Warum nicht? Hat jemand eine (bessere) Idee?
bis dann ,
Jan
Hi ,
ich frage den Wert eines Textfeldes ab.
Wenn nichts drinsteht, soll laut doku JDK 1.2.2 ein leerer
String ("") zurückgegebn werden.
Diesen frage ich mit
if( MeinString==""||MeinString==null)
ab.Leider klappt das nicht!
Warum nicht? Hat jemand eine (bessere) Idee?
Ja,
versuchs mal mit
MeinString.equals("")
Der Vergleich mit == geht nur bei null und bei primitiven
Datentypen.
Wenn du Objekte vergleichen willst, solltest du immer über equals gehen.
Dirk
Hallo,
versuchs mal mit
MeinString.equals("")
Der Vergleich mit == geht nur bei null und bei primitiven
Datentypen.
Wenn du Objekte vergleichen willst, solltest du immer über
equals gehen.
Nicht sollte! Das geht nur so!!!
Ich würde noch folgendes machen:
if( (MeinString!= null) && (MeinString.equals("")) )
…
Wenn man das umgekehrt macht, gibt es einen Laufzeitfehler, weil
du nämlich die Methode eines Objektes aufrufst, die gar nicht
existiert, sprich null ist.
Hallo allerseits!
Nicht, dass ich hier kleinlich sein will. Ich weiß ja was gemeint ist, aber in solchen Foren sollte man doch etwas genauer auf die Sprache achten, da hier sicherlich viele Newbies die Beiträge lesen. Und für die ist sicher eine etwas ausfühlichere Antwort besonders hilfreich.
Der Vergleich mit == geht nur bei null und bei primitiven
Datentypen.
Wenn du Objekte vergleichen willst, solltest du immer über
equals gehen.
iss mir z.B. zu Schwammig, man weiß jetzt zwat irgendwie, daß das so ist, aber warum ist das so???
int z.B. ist ein primitiver Datentyp. Mit dem Code
int a=5;
wird ein Speicherbereich angelegt in dem ein int Platz hat und mit dem Wert 5 belegt. Überall, wo im Code jetzt a verwendet wird heißt das „nimm den Inhalt aus diesem Speicherbereich der mit a markiert ist“. Aus dem Code
if( a==3 ) … wird also zur Laufzeit ein Vergleich zwischen dem aktuellen Inhalt von a und 3.
Alle Variablen, die als Typ eine Klasse haben werden als Referenzvariable bezeichnet. Auch hier muß ein Speicherbereich vorgesehen werden, der ein Objekt dieses Typs aufnehmen kann. Allerdings wird in der Variablen selbst nur ein Zeiger auf diesen Bereich gespeichert. Hat man zwei Objekte o1 und o2, dann wird auch hier bei:
if( o1==o2 ) … der Inhalt von o1 und o2 miteinander verglichen. Dabei handelt es sich aber jetzt um die Zeiger. Das heißt, dieser Vergleich ist dann true, wenn beide Referenzvariablen auf das gleiche Objekt zeigen. Auch das kann in einem Programm eine sinnvolle Operation sein (soviel zu „immer über equals“).
Wenn man überprüfen will, ob der Inhalt von Objekten übereinstimmt, dann ist die Methode equals zu benutzen. Aber Achtung! bei eigenen Objekten ist es ratsam diese Methode entsprechend zu überschreiben.
Gruß
Benky
Moin,
Der Vergleich mit == geht nur bei null und bei primitiven
Datentypen.
Wenn du Objekte vergleichen willst, solltest du immer über
equals gehen.iss mir z.B. zu Schwammig, man weiß jetzt zwat irgendwie, daß
das so ist, aber warum ist das so???
Das ist so, weil Sun es unterlassen hat, dem Token ‚==‘ einen entsprechenden Sinn zu geben. Bei C++ ist das auch bei Objekten kein Problem.
Deine Erklärung ist also als Hintergrund interessant, aber falsch aufgehängt.
Thorsten
Hi Thorsten
Das ist so, weil Sun es unterlassen hat, dem Token ‚==‘ einen
entsprechenden Sinn zu geben. Bei C++ ist das auch bei
Objekten kein Problem.
Falsch! Der Sinn von a==b ist ganz klar definiert: Vergleiche den Inhalt von Variable a mit dem Inhalt mit Variable b!
Wenn ich mich recht entsinne ist es bei C++ zunächst genauso. D.H. es werden lediglich die Referenzen miteinander verglichen. Man kann allerdings bei C++ die Operatoren überladen (was bei Strings bereits der Fall ist) und damit Objekte vom Inhalt her vergleichen. Aber man beachte: Auf einmal hat das == bei einer Variablen eine völlig andere Bedeutung, als bei einer anderen:
Und da hat Java eine klarere Linie. Wenn man den Objekt-Inhalt vergleichen will, dann muss man equals Benutzen.
Deine Erklärung ist also als Hintergrund interessant, aber
falsch aufgehängt.
Wieso falsch aufgehängt??? Es ist der Hintergrund zu diesem Problem! Und nicht nur das. Der Artikel auf den ich mich ursprünglich beziehe hat zwar eine ausreichende Antwort auf das spezielle Problem geliefert, aber wenn man sich hier etwas mehr Mühe gibt und eben auch Hintergrundinfo mitliefert, dann hat das einen wesentlich größeren Nährwert! Hintergrundinfos sind eben nicht so speziell und gelten für eine ganze Reihe von Problemen.
Schau dir den Thread „Arrays in Vectoren speichern - Aber keine Referenz“ an. Da hatte jemand ein Problem, das er sich mit den hier gegebenen Hintergrundinfos selbst beantworten hätte können.
Gruß
Benky
Moin,
Das ist so, weil Sun es unterlassen hat, dem Token ‚==‘ einen
entsprechenden Sinn zu geben. Bei C++ ist das auch bei
Objekten kein Problem.Falsch!
Was genau ist da falsch?
Der Sinn von a==b ist ganz klar definiert: Vergleiche
den Inhalt von Variable a mit dem Inhalt mit Variable b!
Das bezweifle ich nicht.
Wenn ich mich recht entsinne ist es bei C++ zunächst genauso.
Jepp.
Man kann allerdings bei C++ die Operatoren überladen
Jepp
Deine Erklärung ist also als Hintergrund interessant, aber
falsch aufgehängt.Wieso falsch aufgehängt???
Er greift zu kurz, s.u.
Und da hat Java eine klarere Linie.
Im Grunde sind weder Java noch (überladenes) C++ konsequent. Ich denke halt, daß ‚.equals()‘ und der ‚==‘-Operator semantisch völlig austauschbar sind; man hätte die Bedeutung ebensogut umdrehen können. Darum sollte man entweder Operatoren überladen können, damit der Entwickler entscheiden kann (bei Strings interessiert zB. fast nie die Referenz) oder beide Abfragen mit Methoden implementieren sollen.
Thorsten
Deine Erklärung ist also als Hintergrund interessant, aber
falsch aufgehängt.Wieso falsch aufgehängt???
Er greift zu kurz, s.u.
Und da hat Java eine klarere Linie.
Im Grunde sind weder Java noch (überladenes) C++ konsequent.
Ich denke halt, daß ‚.equals()‘ und der ‚==‘-Operator
semantisch völlig austauschbar sind; man hätte die Bedeutung
ebensogut umdrehen können. Darum sollte man entweder
Operatoren überladen können, damit der Entwickler entscheiden
kann (bei Strings interessiert zB. fast nie die Referenz) oder
beide Abfragen mit Methoden implementieren sollen.
Ich finde nach wie vor, dass der == Operator an sich in Java schon konsequent ist. (== == ==, wenn du weißt, was ich meine). Es werden die Inhalte von primitiven (Prozessornahen) Variablen miteinander verglichen, frei von jeglicher Bedeutung.
Das Problem liegt vielmehr darin, daß die primitiven Variablen im Fall von Objektreferenzen an sich in der Regel uninteressant sind, da nur Pointer auf das Objekte.
Zum vergleichen von Objekten wird daher eine Semantik nötig. Und auch das ist in Java bei allen einfachen Objekten mit der equals-Methode konsequent durchgezogen. Wohlgemerkt bei EINFACHEN Objekten.
In deinem Sinne richtig glatt bügeln lässt sich das nur, wenn man komplett auf primitive Datentypen verzichtet und alles mit Objekten und entsprechenden Methoden macht. Aber wer will das schon???
Gruß
Benky
Moin,
(== == ==, wenn du weißt, was ich meine).
So etwa.
Es werden die Inhalte von primitiven (Prozessornahen)
Variablen miteinander verglichen, frei von jeglicher
Bedeutung.
Und genau das hat in einer OO-Sprache nichts zu suchen.
In deinem Sinne richtig glatt bügeln lässt sich das nur, wenn
man komplett auf primitive Datentypen verzichtet und alles mit
Objekten und entsprechenden Methoden macht. Aber wer will das
schon???
Ich. Self und Smalltalk können das.
Und auch das ist in Java bei allen einfachen Objekten mit der
equals-Methode konsequent durchgezogen. Wohlgemerkt bei
EINFACHEN Objekten.
Mit allen, denn es gibt Comparable oder wie das heißt. Was equal ist, mußt Du dann selbst festlegen.
Thorsten
Heiho! :o)
Ich. Self und Smalltalk können das.
Naja, es gibt in Java für jeden Primitive auch ein entsprechendes Objekt. Ist dir nicht geholfen, wenn du einfach mit denen arbeitest?
Oder was machen die genannten Sprachen da anders?
Grüße, Robert
Moin,
Ich. Self und Smalltalk können das.
Naja, es gibt in Java für jeden Primitive auch ein
entsprechendes Objekt. Ist dir nicht geholfen, wenn du einfach
mit denen arbeitest?
Ich hatte kein Problem. Es geht eh gerade nur um Design-Purismus.
Oder was machen die genannten Sprachen da anders?
Ich habe beide noch nicht benutzt, aber was ich über Self weiß, ich wirklich interessant: Alles sind Objekte, auch Methoden; Klassen gibt’s dementsprechend auch nicht. Das hat ein paar nette Konsequenzen, die man ggf. auch mit Java nutzen kann.
(http://www.sun.com/research/self/)
Thorsten
Es werden die Inhalte von primitiven (Prozessornahen)
Variablen miteinander verglichen, frei von jeglicher
Bedeutung.Und genau das hat in einer OO-Sprache nichts zu suchen.
Auch in OO-Sprachen braucht man einen Satz an vordefinierten primitiven Datentypen und Operationen darauf. Wie willst du für eine Klasse Integer eine Methode add definieren, wenn du keinen + Operator zur Verfügung hast und keinen primitiven Datentyp, der eine Zahl repräsentieren kann??
In deinem Sinne richtig glatt bügeln lässt sich das nur, wenn
man komplett auf primitive Datentypen verzichtet und alles mit
Objekten und entsprechenden Methoden macht. Aber wer will das
schon???Ich. Self und Smalltalk können das.
Java hat ebenfalls für jeden primitiven Datentyp ein pedant, aber wo liegt der Sinn darin wirklich alles mit Objekten zu machen?? Wir haben es nun mal mit realen Prozessoren zu tun. Und solange die nicht OO sind, handelt man sich mit der reinen OO-Lehre nur eine schlechtere Performance ein. Ruf doch 10.000mal von 2 Integer-Objekten die Methode equals auf. Macht genau das gleiche wie == auf primitiven Typen, braucht dafür aber zusätzliche Methodenaufrufe.
Und auch das ist in Java bei allen einfachen Objekten mit der
equals-Methode konsequent durchgezogen. Wohlgemerkt bei
EINFACHEN Objekten.Mit allen, denn es gibt Comparable oder wie das heißt. Was
equal ist, mußt Du dann selbst festlegen.
Das „EINFACHEN Objekten“ in meiner Aussage bezieht sich auf die in der Klasse Object definierte standard-Implementierung von equals. Sobald man anfängt die Klasse mit Infos anzureichern, die mit den Eigenschaften des Objektes eigentlich nichts zu tun haben, dann reicht dieses equals nicht mehr aus und man muss es, wie du erwähnst selbst implementieren.
Aber was ist, wenn das equals selbst in einem bestimmten Kontext zu betrachten ist?? Beispiel: Klasse Motor. In einem Kontext möchte ich 2 Motoren bzgl. des Hubraumes miteinander vergleichen, in einem anderen Kontext bzgl. der Zylinder.
Äh, und noch was, vielleicht sollten wir langsam mit dem Thread mal umziehen in ein Philosophie-Brett *schmile*
Gruß
Benky
Ich hatte kein Problem. Es geht eh gerade nur um
Design-Purismus.
Verstehe, es spricht der Perfektionist … 
Ich habe beide noch nicht benutzt, aber was ich über Self
weiß, ich wirklich interessant:
Danke für die URL, liest sich wirklich ziemlich interessant.
Grüße, Robert
Moin,
Und genau das hat in einer OO-Sprache nichts zu suchen.
Auch in OO-Sprachen braucht man einen Satz an vordefinierten
primitiven Datentypen und Operationen darauf. Wie willst du
für eine Klasse Integer eine Methode add definieren, wenn du
keinen + Operator zur Verfügung hast und keinen primitiven
Datentyp, der eine Zahl repräsentieren kann??
Wie das in der Methode geregelt wird, interessiert mich nicht. Wichtig ist, was hinten 'rauskommt, und das kann auch in diesen Fällen ein Objekt sein.
Java hat ebenfalls für jeden primitiven Datentyp ein pedant,
aber wo liegt der Sinn darin wirklich alles mit Objekten zu
machen??
Der Sinn ist, daß man alles mit Objekten machen kann. Der Wechsel zwischen Primitiven und den kapselnden Klassen macht wirklich keinen Spaß.
Wir haben es nun mal mit realen Prozessoren zu tun.
Und solange die nicht OO sind, handelt man sich mit der reinen
OO-Lehre nur eine schlechtere Performance ein.
Weil alle Leute schlechtere Performance haben wollen, ist OOP auch so weit verbreitet.
Ruf doch 10.000mal von 2 Integer-Objekten die Methode equals
auf. Macht genau das gleiche wie == auf primitiven Typen,
braucht dafür aber zusätzliche Methodenaufrufe.
Ist bestimmt langsamer, na und?
Aber was ist, wenn das equals selbst in einem bestimmten
Kontext zu betrachten ist?? Beispiel: Klasse Motor. In einem
Kontext möchte ich 2 Motoren bzgl. des Hubraumes miteinander
vergleichen, in einem anderen Kontext bzgl. der Zylinder.
Interessant, aber das wäre eine recht seltsame Verwendung von ‚equals‘. ‚Gleich‘ können die Motoren nur sein, wenn sie gleich sind, sonst solltest Du derMotor.Hubraum().equals(…) verwenden (‚is a‘ und ‚has a‘).
Äh, und noch was, vielleicht sollten wir langsam mit dem
Thread mal umziehen in ein Philosophie-Brett *schmile*
Ich verteile meine Geschwätzigkeit überall.
Thorsten
Hallo,
so genau wollt ich 's gar nicht wissen.
Jan