Macht es Sinn, dass Objekte als Referenzen gespeichert werden, wenn die Sprache keine Pointer hat?
-
In Sprachen, die keine Pointer besitzen, werden Objekte meist in Referenzen gespeichert, sodass
int a = 3;
int b = a;
b = 3;
anders funktioniert als
objectInt a = new objectInt(3);
objectInt b = a;
b = 3;Für mich macht das keinen Sinn. Welche Vorteile resultieren daraus?
-
Wenn das die Sprache mit der NullPointerException ist, frag ich mit, ob das nicht doch Pointer sind.
Vorteile hast du z.B. bei der übergabe an Methoden
-
Objekte haben in der OOP drei wichtige Eigenschaften:
* Zustand
* Verhalten
* IdentitätIn einer Sprache ohne Pointer oder Referenzen (das ist in dieser Sichtweise das gleiche) funktioniert das mit der Identität nicht. Wie willst du ein bestimmtes Objekt an eine Methode übergeben, wenn da nur die Kopie ankommt?
-
mit keine Pointer meine ich leglich keine Pointer, die man selbst hinschreibt.
Objekte haben in der OOP drei wichtige Eigenschaften:
* Zustand
* Verhalten
* IdentitätIn einer Sprache ohne Pointer oder Referenzen (das ist in dieser Sichtweise das gleiche) funktioniert das mit der Identität nicht. Wie willst du ein bestimmtes Objekt an eine Methode übergeben, wenn da nur die Kopie ankommt?
Wieso funktioniert das mit der Identität nicht? Was meinst du damit?
Ich würde das Objekt einfach per Call-by-Reference übergeben, sofern die Sprache das unterstützt.
-
Gastaccount schrieb:
Ich würde das Objekt einfach per Call-by-Reference übergeben, sofern die Sprache das unterstützt.
das schrieb bashar bereits, wenn man die identität eines objekts braucht, dann braucht man entweder eine referenz, einen pointer oder sonstwas, um auf das konkrete objekt zu verweisen. deshalb haben oo-sprachen (und nicht nur diese) entweder pointer oder referenzen.
-
Aber wieso?
Um die Objekte gemeinsam verwenden zu können reicht ja auch call-by-ref. und man braucht nicht gleich implizit immer Referenzen/Pointer, wenn es sich um ein Objekt handelt?
-
Gastaccount schrieb:
Aber wieso?
Um die Objekte gemeinsam verwenden zu können reicht ja auch call-by-ref.wobei dieses 'ref' ja 'referenz' heisst, also ein verweis auf das objekt ist. die gleiche funktion würde auch ein pointer erfüllen können, oder wie meinst du das?
-
Ja.
Aber die Frage ist ja nicht ob Referenzen/Pointer allgemein Sinn machen, sondern viel mehr ob es Sinn macht, dass auf Objekte von vornerein nur mit einer Referenz verwiesen wird, anstatt nur bei Bedarf eine Referenz zu verwenden.
-
das ist doch irrelevant. das eine mal (i.d. einen sprache) wird automatisch eine kopie übergeben, in der anderen automatisch eine referenz. aber es ist ja nicht so, dass man das jeweils andere verhalten nicht erzwingen könnte.
-
klar, du kannst dir ja was basteln, das objekte z.b. anhand ihres namens wiederfindet.
CreateObject ("Pinocchio", new Holzfigur); ... // und dann, irgendwo anders im code ... Holzfigur p = FindObject ("Pinocchio"); p.NaseVerlaengernInZentimetern(256); ...
-
das ist doch irrelevant. das eine mal (i.d. einen sprache) wird automatisch eine kopie übergeben, in der anderen automatisch eine referenz. aber es ist ja nicht so, dass man das jeweils andere verhalten nicht erzwingen könnte.
Eben. Also warum macht man dann diese Unterscheidung, sodass man bei "normalen" Typen explizit call-by-ref fordern muss und bei objekten explizit call-by-val. Das verkompliziert das ganze doch nur unnötig
-
call-by-ref reicht nicht, wie speicherst du sonst einen Verweis (zB als Attribut)?
-
dass auf Objekte von vornerein nur mit einer Referenz verwiesen wird, anstatt nur bei Bedarf eine Referenz zu verwenden.
Der Fall dass man eine Referenz übergeben will (bzw. sollte) ist allerdings meiner Erfahrung nach viel häufiger als der Fall dass man eine Kopie übergeben will (bzw. sollte). Von daher macht "default=by reference" schon Sinn.
Klar ist es wenn man z.B. von C++ her kommt gewöhnungsbedürftig dass man zwischen den eingebauten value types (int, short oder wie sie in der jeweiligen Sprache dann heissen) und den Objekttypen unterscheiden muss, aber wirklich unlogisch ist es auch nicht. Auch in C++ gibt es einige Unterschiede zwischen UDTs und eingebauten Typen.Was mich dagegen wirklich nervt ist wenn es kein "const" gibt. Mit "const" ist "pass by reference" nämlich normalerweise überhaupt garkein Problem.
-
hustbaer schrieb:
Was mich dagegen wirklich nervt ist wenn es kein "const" gibt. Mit "const" ist "pass by reference" nämlich normalerweise überhaupt garkein Problem.
wieso geht's denn nicht richtig ohne 'const'?
-
Gehen tut alles, bloss lästig ist es.
-
Gastaccount schrieb:
Ja.
Aber die Frage ist ja nicht ob Referenzen/Pointer allgemein Sinn machen, sondern viel mehr ob es Sinn macht, dass auf Objekte von vornerein nur mit einer Referenz verwiesen wird, anstatt nur bei Bedarf eine Referenz zu verwenden.Klar kann es Sinn machen explizit Referenzen zu verlangen. Aber damit baust du ja explizit wieder Referenzen in die Sprache ein, waehrend du bei dem gaengigen Ansatz: jedes Objekt wird nur Referenziert keine direkten Referenzen hast.
Zumal sich das Problem dann mit dem Loeschen des Objektes wieder ergibt und du ploetzlich nicht mehr garantieren kannst dass alle deine Referenzen gueltig sind, was sie irgendwie zu dummen Zeigern macht und du dir im Endeffekt ins Bein geschossen hast, da deine Referenzen alle Nachteile von Zeigern und Referenzen vereinigen aber keine wirklichen Vorteile.
Falls es bei dem const um Java gehen sollte, dann ist dort der Ansatz einfach ein komplett anderer: naemlich Immutable.
-
hustbaer schrieb:
Gehen tut alles, bloss lästig ist es.
Da gabs doch schonmal einen Thread ueber const-correctness. Finds immernoch ueberfluessig const-ref zu haben.
-
DEvent schrieb:
hustbaer schrieb:
Gehen tut alles, bloss lästig ist es.
Da gabs doch schonmal einen Thread ueber const-correctness. Finds immernoch ueberfluessig const-ref zu haben.
Du schon, ich nicht, so sind Menschen unterschiedlich.
-
Shade Of Mine schrieb:
Falls es bei dem const um Java gehen sollte, dann ist dort der Ansatz einfach ein komplett anderer: naemlich Immutable.
...und das keyword 'final'. wobei bei primitiven datentypen das Java-final die gleiche wirkung hat, wie in C das 'const'.