Original von Tom9811
Wenn du das auf value-Objects beschränkst, ist es in der Tat so, dass ein Copy Sinn macht. Deshalb schreib ich ja auch Ausnahme! Du schriebst "nie so machen".

Ich bezog mich eindeutig auf Setter für Strings: Die Setter-Methoden für die Strings würde ich so niemals implementieren. Ich glaube, Du solltest mal gründlicher lesen.

Original von Tom9811
Value-Objetcs sind das Gegenteil von KVO, KVC, CB. Sie sind dafür da, Daten unabänderlich von der Außenwelt selbst zu halten.

Ja, genau. Und in einem Objekt, wie hier z.B. Worker, will ich nicht, das mir irgendjemand von außen, d.h. ohne über die Setter-Methoden zu gehen, an den Objekt-Eigenschaften herumpfuscht. Das bekomme ich dann nicht mit und habe dann eventuell Probleme, wenn es z.B. objektinterne Abhängigkeiten gibt.

Original von Tom9811
Das ist die Ausnahme, die zudem Speicher kostet. In der Regel will du Beziehungen haben, nicht private Kopien. Wenn jemand einen Namen in einem TableView ändert, soll sich das automatisch fortsetzen. Es soll nicht irgendwo eine private, eigene Kopie stehen bleiben.

Davor bist Du auch bei Deiner Art Setter nicht sicher, weil man Objekte am Setter vorbei ändern kann.

Original von Tom9811
In der Tat läuft das bei einem immutable af das gleiche heraus. Wer garantiert dir, dass es ein immutable ist?

Keiner, deshalb muss ich eine Kopie machen, wenn ich nicht will, dass jemand anders ohne mein Wissen an meinen Objekteigenschaften rumschraubt.

Original von Tom9811
Außerdem: Wenn du nur einen retain machen möchtest, warum in Gottes Namen machst du dann nicht einen retain, sondern verschwendest Speicher um das gleiche uneränderliche PObjekt zweimal zu halten? Arbeitet deine Familie in der Speicherindustrie?

Ich möchte bei einer Setter-Methode für NSStrings eine Kopie, wenn der übergebene String mutable ist und ein retain, wenn er immutable ist. Ein copy macht das bei NSString genau so.

Original von Tom9811
Für die üblichen Accessoren mit KVO, KVC und Cb gibt es Probleme.

Ich konnte noch keine feststellen.

Original von Tom9811
Außerdem müllst du damit den Speicher zu.

Wieso? Sobald der Autoreleasepool geleert wird, gibt es keinen Unterschied mehr, außer ich muss wirklich eine Kopie machen, um mir nicht ins Handwerk pfuschen zu lassen. Und noch einmal: von immutable Strings macht Cocoa keine Kopie, sondern retaint das Objekt.

Michael

Zitat:
Original von Tom9811
Wenn du das auf value-Objects beschränkst, ist es in der Tat so, dass ein Copy Sinn macht. Deshalb schreib ich ja auch Ausnahme! Du schriebst "nie so machen".

Ich bezog mich eindeutig auf Setter für Strings: Die Setter-Methoden für die Strings würde ich so niemals implementieren. Ich glaube, Du solltest mal gründlicher lesen.

Das glaube ich von dir.
Ob etwas ein value ist oder ein entity, hängt nicht vom Datentypen ab.

Zitat:
Original von Tom9811
Value-Objetcs sind das Gegenteil von KVO, KVC, CB. Sie sind dafür da, Daten unabänderlich von der Außenwelt selbst zu halten.

Ja, genau. Und in einem Objekt, wie hier z.B. Worker, will ich nicht, das mir irgendjemand von außen, d.h. ohne über die Setter-Methoden zu gehen, an den Objekt-Eigenschaften herumpfuscht. Das bekomme ich dann nicht mit und habe dann eventuell Probleme, wenn es z.B. objektinterne Abhängigkeiten gibt.

Ich würde ganz häufig darauf verweisen. Wenn ich etwa ein Fabrik-Objekt habe und dort in einem Array verweise auf die Worker setze, die dort arbeiten. Mir wäre es ganz lieb, wenn Änderungen im verwiesenen Worker-Objekt weitergereicht würden. Ürbigens ist das "erumpfuschen" gleichgültig, weil es ja immer konsistent bleibt: Danke entities.

Also ich finde, dass ist ein entity.

Aber gut, man kann das ja so und so sehen. Aber auch noch die Behauptung, Strings seien stets values, schmeckt mir in der Tat nicht. Das hängt wie gesagt nicht vom Datentypen ab.

Zitat:
Original von Tom9811
Das ist die Ausnahme, die zudem Speicher kostet. In der Regel will du Beziehungen haben, nicht private Kopien. Wenn jemand einen Namen in einem TableView ändert, soll sich das automatisch fortsetzen. Es soll nicht irgendwo eine private, eigene Kopie stehen bleiben.

Davor bist Du auch bei Deiner Art Setter nicht sicher, weil man Objekte am Setter vorbei ändern kann.

Ja? Wie denn? Siehe unten.
Aber nebenbei: Niemand schützt 100% vor Fehlern. Das sollte mich nicht davon abhalten, mnöglichst nahe daran zu kommen.

In diesem Falle gibt es übrigens keine andere Möglichkeit als einen internen Fehler in meiner Klasse. Denn an die Eigenschaft kommt in der Tat niemand außerhalb heran. Ich finde das ganz günstig, gerade beim Debugging.

Zitat:
Original von Tom9811
In der Tat läuft das bei einem immutable af das gleiche heraus. Wer garantiert dir, dass es ein immutable ist?

Keiner, deshalb muss ich eine Kopie machen, wenn ich nicht will, dass jemand anders ohne mein Wissen an meinen Objekteigenschaften rumschraubt.

Es kann keiner außerhalb deines Setters an den Objekteigenschaften herumschrauben. Übrigens ist es mir lieber, wegen eines Fehlers in einem Programm stat "müller" "Müller-Ups" in dem Modell stehen zu ahben, aber es weiterhin konsistent zu halten, als ein gesichters "Müller", dass zu einem "Müller-Ups" in einem temp inkonsistent ist.

Wenn du den doppelten Zeiger meinst, der ja eine Folge deiner Denke ist, nicht die Beseitigung, so bleibt eben das Datenmodell immer konsistent. Das ist der riesige Vorteil.

Wenn du eine Zeile weiter mit deinem temp wieder in den Workern suchst, findest du -Ups- gar keinen entsprechenden Eintrag mehr. Die Daten sind jetzt inkonsistent, das ist viel, viel, schlimmer und viel schwieriger zu finden.

Bei meinen Settern gibt es das gar nicht erst. ein Zeiger auf das hinterlegte Objekt wird mittel [self eigenschaft] geholt. Punkt. Einen temp brauce ich nicht. Ich komme gar nicht erst auf die Idee, mir eine solche Variable anzulegen.
Du versuchst einen Fehler durch einen anderen Fehler auszugleichen und das auf Kosten der Datenkonsistenz. Das ist für micht den Teufel mit dem Beelzebub austreiben.

Ich kan nur ein Copy machen, wenn ich eine private Kopie haben will, die abgeschottet ist, siehe dein Zitat. Dann ist klar, dass diese private Kopie nie mehr als Referenz taugt. Das wäre ein Widerspruch in sich. OC, Cocoa und die darauf aufbauenden Technologien KVO, KVC, CB sind aber gerade Technologien, um Objekte zu referenzieren. Die Kopie muss daher die strikte Ausnahme bleiben, auch wenn sie manchmal sinnvoll ist.

Zitat:
Original von Tom9811
Außerdem müllst du damit den Speicher zu.

Wieso? Sobald der Autoreleasepool geleert wird, gibt es keinen Unterschied mehr, außer ich muss wirklich eine Kopie machen, um mir nicht ins Handwerk pfuschen zu lassen. Und noch einmal: von immutable Strings macht Cocoa keine Kopie, sondern retaint das Objekt.

Selbstevrständlich gibt es einen Unterschied. Dein Const-String-Objekt liegt jetzt als Konstante und als Kopie einer Konstanten im Speicher!

Wenn du komplizierte Beziehungen hast, siehe mein Beispiel, ist jede Beziehung eine upzudatende Kopie (möglicherweise geht das sogar mit KVO, wenn ich länger darüber nachdenke.). Du hast also jedes Datum 3, 4, 5 Mal im Speeicher liegen.

Original von Tom9811
Ich würde ganz häufig darauf verweisen. Wenn ich etwa ein Fabrik-Objekt habe und dort in einem Array verweise auf die Worker setze, die dort arbeiten. Mir wäre es ganz lieb, wenn Änderungen im verwiesenen Worker-Objekt weitergereicht würden. Ürbigens ist das "erumpfuschen" gleichgültig, weil es ja immer konsistent bleibt: Danke entities.

Also ich finde, dass ist ein entity.

Die "Worker-Instanz" ist ein entity, ja. Nicht eine Eigenschaft des Workers.

Original von Tom9811
Aber gut, man kann das ja so und so sehen. Aber auch noch die Behauptung, Strings seien stets values, schmeckt mir in der Tat nicht. Das hängt wie gesagt nicht vom Datentypen ab.

Sicher gibt es auch da "Ausnahmen"

Original von Tom9811

Original von Tom9811
Das ist die Ausnahme, die zudem Speicher kostet. In der Regel will du Beziehungen haben, nicht private Kopien. Wenn jemand einen Namen in einem TableView ändert, soll sich das automatisch fortsetzen. Es soll nicht irgendwo eine private, eigene Kopie stehen bleiben.

Original von Michael
Davor bist Du auch bei Deiner Art Setter nicht sicher, weil man Objekte am Setter vorbei ändern kann.

Ja? Wie denn?

Ich dachte, das wäre bereits durch meine ganz weit oben stehende 'main' Funktion klar geworden. Nun gut, dann hänge ich hier noch mal eine Demo dran. Diese zeigt, dass mit Deiner Art von Setter-Methoden die Cocoa Bindings versagen und zusätzlich auch noch Abhängigkeiten im Modell vermurkst werden. Ja ja, ich weiß, Du würdest das wieder ganz anders programmieren. Aber dies ist nur eine Demo, die eine Situation darstellen soll, die in der Praxis vorkommen kann.

Original von Tom9811
In diesem Falle gibt es übrigens keine andere Möglichkeit als einen internen Fehler in meiner Klasse.

Jo, und zwar in der Setter-Methode.

Original von Tom9811
Denn an die Eigenschaft kommt in der Tat niemand außerhalb heran.

Und hier irrst Du. Schau Dir die Demo an.

Original von Tom9811
Es kann keiner außerhalb deines Setters an den Objekteigenschaften herumschrauben.

Außerhalb meines Setters nicht, außerhalb Deines Setters schon. Siehe Demo.

Original von Tom9811
Übrigens ist es mir lieber, wegen eines Fehlers in einem Programm stat "müller" "Müller-Ups" in dem Modell stehen zu ahben, aber es weiterhin konsistent zu halten, als ein gesichters "Müller", dass zu einem "Müller-Ups" in einem temp inkonsistent ist.

Anscheinend haben wir eine unterschiedliche Vorstellung von objektorientierter Programmierung.

Original von Tom9811
Wenn du den doppelten Zeiger meinst, der ja eine Folge deiner Denke ist, nicht die Beseitigung, so bleibt eben das Datenmodell immer konsistent.

Siehe Demo. Wenn Du interne Abhängigkeiten im Modell hast, hast Du schneller Inkonsistenzen im Modell, als Du denkst.

Original von Tom9811
Bei meinen Settern gibt es das gar nicht erst. ein Zeiger auf das hinterlegte Objekt wird mittel [self eigenschaft] geholt. Punkt. Einen temp brauce ich nicht. Ich komme gar nicht erst auf die Idee, mir eine solche Variable anzulegen.

Sorry, aber Du hängst Dich viel zu sehr an einem konkreten Beispiel auf. Ist es denn so unvorstellbar, dass man einen NSMutableString hat, der zu einem bestimmten Zeitpunkt einem Objekt x als Wert einer Eigenschaft übergeben wird und anschließend weiter verarbeitet werden muss, ohne das der Wert der Eigenschaft im Objekt x sich ändern darf?

Original von Tom9811
Außerdem müllst du damit den Speicher zu.

Original von Michael
Wieso? Sobald der Autoreleasepool geleert wird, gibt es keinen Unterschied mehr, außer ich muss wirklich eine Kopie machen, um mir nicht ins Handwerk pfuschen zu lassen. Und noch einmal: von immutable Strings macht Cocoa keine Kopie, sondern retaint das Objekt.

Selbstevrständlich gibt es einen Unterschied. Dein Const-String-Objekt liegt jetzt als Konstante und als Kopie einer Konstanten im Speicher!

Du solltest wirklich gründlicher lesen. Ich habe jetzt schon mehrfach gesagt, dass Cocoa keine Kopien von immutable Strings anlegt. Theoretisieren hilft hier anscheinend nicht weiter, daher hier mal Praxis:

Theorie ist schön und notwendig, aber die Praxis sollte man bei aller Theorie nicht vergessen. Da sieht es nun mal nicht immer wie in der Theorie aus.

Michael

Ob die Eigenschaft des Workers eine ist, wissen wir in der Tat nicht, da hast du Recht. Das kommt aber auch bei Strings häufig vor. Ich lege etwa ganz gerne IDs in Strings an. darf ich dich ann deine Aussage erinnern:

Die Setter-Methoden für die Strings würde ich so niemals implementieren (auch wenn Du mich jetzt vierteilen wirst, Tom ),

Wenn du meintest, dass du nicht Setter-Methoden für Strings, die reine values sind, niemals os implemmentiern würdest, mag das ja noch angehen. Aber das stand da nicht. Für mich hat die Unterscheidung entities/values auch nichts mit dem Datentypen zu tun.

Ansonsten sehe ich deas weiterhin so. Das Problem ist nicht der Setter, sondern der zweite Zeiger. Und ja: Für mich ist es unvorstellbar, dass isch jemand einen Zeiger holt, den setzt und dann bei einer Änderung des verzeigerten Objektes meint, dies sei privat. Ja, vollkommen unvorstellber. Das hat auch nichts mit Settern zu tun, sondern ist ein generelles Problem.

Wer dennoch der Meinung ist, dies sei nicht so, hat Zeiger nicht verstanden. (Damit meine ich nicht dich.)

Der Verweis auf die Implementierung ist vom Grundsatz falsch: Die interessiert mich nicht. Übrigens haben wir es hier mit einem generellen Problem zu tun und nicht mit einem speziellen. Schließlich frage ich mich, wenn du dich schon auf die Implementierung verlässt -für mich ein Kardinalfehler!- du dann nicht einfach ein retain schickst anstelle eines copys. Deine Argumentation ist doch:

Das Kopie ist sicherer, es ist ohnehin nur ein retain, deshalb ist es gleichgültig.

Sorry, das ist für mich in sich widersprüchlich.

Original von Tom9811
Ob die Eigenschaft des Workers eine ist, wissen wir in der Tat nicht, da hast du Recht.

Der Entwickler einer Klasse sollte schon wissen, was in einem Objekt was ist.

Original von Tom9811
Das kommt aber auch bei Strings häufig vor. Ich lege etwa ganz gerne IDs in Strings an. darf ich dich ann deine Aussage erinnern:

Die Setter-Methoden für die Strings würde ich so niemals implementieren (auch wenn Du mich jetzt vierteilen wirst, Tom ),

Und was machst Du mit solchen IDs? Ich habe keine Ahnung, was Du mir hiermit sagen willst.

Original von Tom9811
Wenn du meintest, dass du nicht Setter-Methoden für Strings, die reine values sind, niemals os implemmentiern würdest, mag das ja noch angehen. Aber das stand da nicht. Für mich hat die Unterscheidung entities/values auch nichts mit dem Datentypen zu tun.

Meinetwegen formulieren wir das auch so. Ich habe jedenfalls noch keinen Anwendungsfall gehabt, in dem meine Art von Setter bei NSStrings versagt hätte.

Original von Tom9811
Ansonsten sehe ich deas weiterhin so. Das Problem ist nicht der Setter, sondern der zweite Zeiger. Und ja: Für mich ist es unvorstellbar, dass isch jemand einen Zeiger holt, den setzt und dann bei einer Änderung des verzeigerten Objektes meint, dies sei privat.

Nun, ich betrachte das etwas anders. Ich setze Objekte, keine Zeiger. Wenn daher die Gefahr besteht, dass sich das Objekt ohne mein Wissen verändern kann und ich das nicht will, dann muss ich halt 'ne Kopie machen. In der Regel ist die bei NSString-Instanzvariablen der Fall.

Original von Tom9811
Der Verweis auf die Implementierung ist vom Grundsatz falsch: Die interessiert mich nicht.

Also, mich interessiert meine eigene Implementierung einer Klasse sehr. Als Anwender einer Klasse will ich mich auch nicht um Dinge kümmern, die in der Klasse intern ablaufen (siehe Demo). Das ist Sache der Klasse.

Original von Tom9811
Übrigens haben wir es hier mit einem generellen Problem zu tun und nicht mit einem speziellen. Schließlich frage ich mich, wenn du dich schon auf die Implementierung verlässt -für mich ein Kardinalfehler!- du dann nicht einfach ein retain schickst anstelle eines copys. Deine Argumentation ist doch:

Das Kopie ist sicherer, es ist ohnehin nur ein retain, deshalb ist es gleichgültig.

Es ist eben nicht gleichgültig, weil man einer Methode mit einem NSString-Parameter auch einen NSMutableString übergeben kann. Ich darf mich dann nicht darauf verlassen, dass derjenige, der mir den NSMutableString übergibt, diesen nicht mehr verändert. Deshalb muss ich in dem Fall kopieren. Wenn Du es erlauben willst, dass man so an Deinen Settern vorbei direkt die Instanzvariablen von außen verändern kann, widerspricht das meiner Vorstellung von Datenkapselung.

Michael

Updated

Zitat:

Original von Tom9811
Ob die Eigenschaft des Workers eine ist, wissen wir in der Tat nicht, da hast du Recht.

Der Entwickler einer Klasse sollte schon wissen, was in einem Objekt was ist.

Jetzt verstehe ich dich gar nicht mehr. _Du_ hast doch geschrieben, dass du _nie_ einen String referenzieren würdest!

Für _dich_ ist es doch gerade gleich, was geschieht!

BTW: Wir beide wissen nicht, was ein Entwickler mit einem String als Member macht. _Ich_ würde das auch nie pauschal beantworten.

Zitat:

Original von Tom9811
Das kommt aber auch bei Strings häufig vor. Ich lege etwa ganz gerne IDs in Strings an. darf ich dich ann deine Aussage erinnern:

Zitat:

Die Setter-Methoden für die Strings würde ich so niemals implementieren (auch wenn Du mich jetzt vierteilen wirst, Tom ),

Und was machst Du mit solchen IDs? Ich habe keine Ahnung, was Du mir hiermit sagen willst.

Ich will damit sagen, dass es durchauss Fälle, ich meine sogar die Mehrzahl, gibt, indem Strings referenzen sind. Einen ID referenziere ich häufig. Dann will ich keine Kopie. Du hingegen sagst, dass es immer ein value-Objekt sei, jedenfalls so zu behandeln - unteschiedslos. So habe ich jedenfalls die zitierte Stelle verstanden ("niemals").

Externe Setter-Objekte setze ich übrigens immer als Referenz. Wenn der Nutzer einer Klasse der Meinung ist, er wolle unabhängige Sicherheit, so kann r sich selbst eine Kopie anfertigen oder aber eine Kopie setzen. Das bleibt Sache des Nutzers. Mein Setter ermöglicht beide Wege.

Es geht auch nicht darum, dass das versagt. Es ist einfach ein anderer Ansatz. Er erzeugt zusätzliche Objekte sogar da, wo eigentlich Objekte geteilt werden. Das ist schlicht Speicherverschwendung.

Ich sehe das auch nicht so, dass ich Objekte setze. Das ist unser Grundunterschied. Ich setze Referenzen. Grundsätzlich basiert KVO, KVC, CB auf Referenzen. Extra für Referenzen ist das RC erfunden worden, was du gar nicht brauchst. Ich halte alles 4 für Schlüsseltechnologien, die nicht nur einfach dabei sind.

Und das Problem hast du nicht nur bei Instanzvariablen. Das ist generell


Das ist eigentlich sogar Absicht bei Zeigern. Man muss das freilich berücksichtigen.

Zitat:

Original von Tom9811
Der Verweis auf die Implementierung ist vom Grundsatz falsch: Die interessiert mich nicht.

Also, mich interessiert meine eigene Implementierung einer Klasse sehr. Als Anwender einer Klasse will ich mich auch nicht um Dinge kümmern, die in der Klasse intern ablaufen (siehe Demo). Das ist Sache der Klasse.

Ebendt(tm)! Deshalb solltest du auch nicht wegen eines Missverständnisses des Users über die Arbeitsweise von Pointern deine Implementation von Worker ändern. Genau das meine ich auch!

Und deshalb solltest du ungekehrt nicht bei der Implemmentierung von Worker daran denken, was NSString intern macht.

Zu äußeren Zeiger
Was in meinem referenzierten Objekt abgeht, darf mich nicht interessieren. Das hole ich jedesmal. Du akzeptierst ja auch ansonsten, dass 3 Leute Worker referenzieren und es jeder ändern kann. Jetzt mwird mir das klar. Du gehst davon aus, dass NSstring ein Skalar ist, behandelst ihn jedenfalls so. Das ist aber irgendein Objekt, welches ich referenziere. Und wie jedes andere Objekt kann sich das laufend ändern. Wenn ich Änderungen explizit mitbekommen will, dann nehme ich KVO. Um mir über deine Meinung klar zu werden, schau bitte mal auf die Graphik in dem Artikel. Bist du der Meinung, dass der Member owner dort, eine Kopie anlegen sollte? Oder meinst du dort auch, dass man eine Kopie machen sollte?

Wenn du der Meinung bist, dass dort eine Referenz richtig ist, dann verstehe ich nicht, warum du das bei irgendeinem String anders siehst. Das ist genauso irgendein Objekt.

Wenn du der Meinung bist, dass dort ebenfalls die Address-Instanzen kopiert werden sollten, so verstehe ich nicht, warum. Das ist für mich einfach Speicehrverschwendung, zumal ich dann ja ohnehin gleich wieder alles nachhalten muss, also sogleich eine neue Kopie anlege.

Jedenfalls hat das von dir geschilderte Problem nichts mit NSString zu tun. Bei der Address-Instanz tritt das Problem genauso auf. Ich halte das einfach nicht für ein Problem, sondern für eine Eigenschaft von Settern.

BTW: Wo das Problem wirklich brennt, ist bei einer to-many-Referenz, da ein zurückgegebenes Array gar nicht kontrolliert werden kann. Da helfen aber auch keine Kopien.

Original von Tom9811

Original von Michael
Der Entwickler einer Klasse sollte schon wissen, was in einem Objekt was ist.

Jetzt verstehe ich dich gar nicht mehr. _Du_ hast doch geschrieben, dass du _nie_ einen String referenzieren würdest!
...
Für _dich_ ist es doch gerade gleich, was geschieht!

BTW: Wir beide wissen nicht, was ein Entwickler mit einem String als Member macht.

Ich habe ehrlich gesagt ein wenig Probleme mit Deinen Gedankensprüngen. Wenn ich von Setter-Methoden für String-Instanzvariablen rede, dann bin ich doch mit der Implementierung einer Klasse beschäftigt. Wieso soll ich da nicht wissen, welche Eigenschaften diese Klasse hat?

Original von Tom9811

Original von Michael
Und was machst Du mit solchen IDs? Ich habe keine Ahnung, was Du mir hiermit sagen willst.

Ich will damit sagen, dass es durchauss Fälle, ich meine sogar die Mehrzahl, gibt, indem Strings referenzen sind. Einen ID referenziere ich häufig.

Das Du diese ID referenzierst habe ich mir schon gedacht. Aber wie verwendest Du die dann? Was bringt mir das? Ich habe es immer noch nicht verstanden.

Original von Tom9811
Ich sehe das auch nicht so, dass ich Objekte setze. Das ist unser Grundunterschied. Ich setze Referenzen. Grundsätzlich basiert KVO, KVC, CB auf Referenzen.

Dann erkläre mir doch mal, warum das in der Demo nicht funktioniert. Ich habe da in der Demo zwei Referenzen auf einen String. Eine in der -awakeFromNib des AppControllers und eine dann im Personenobjekt. Wenn ich jetzt Deine Theorie richtig verstanden habe, dann sollte wenn ich über die Referenz in -awakeFromNib den String ändere, über KVO der PersonController das mitbekommen. Tut er aber nicht, sonst würde in den Vornamen-Feldern das gleiche stehen.

Original von Tom9811

Quellcode

1. NSString* myString;
3. myString = ...
4. ...
5. NSString* tempString = myString;
6. ...
7. [tempString append...]; // Hier ändert sich auch myString;

Das ist eigentlich sogar Absicht bei Zeigern. Man muss das freilich berücksichtigen.

Hier gibt es wohl eher ein "selector not recognized" Klar muss man das berücksichtigen und ich tue das eben gegebenenfalls auch im Setter. So ist nun mal mein Programmierstil.

Original von Tom9811
Ebendt(tm)! Deshalb solltest du auch nicht wegen eines Missverständnisses des Users über die Arbeitsweise von Pointern deine Implementation von Worker ändern.

Ich halte nichts davon, die Benutzung einer Klasse nur deswegen zu erschweren, nur weil ich alle Setter nach Schema F programmieren soll. Schau Dir mal -setString: von NSWindow an. Diese Methode macht auch eine Kopie vom Parameter, wenn man einen NSMutableString übergibt.

Original von Tom9811
Zu äußeren Zeiger
Was in meinem referenzierten Objekt abgeht, darf mich nicht interessieren. Das hole ich jedesmal. Du akzeptierst ja auch ansonsten, dass 3 Leute Worker referenzieren und es jeder ändern kann. Jetzt mwird mir das klar. Du gehst davon aus, dass NSstring ein Skalar ist, behandelst ihn jedenfalls so.

Worker ist auch kein String. Worker hat Accessor-Methoden. Hat NSString Accessor-Methoden, wie Worker?

Original von Tom9811
Das ist aber irgendein Objekt, welches ich referenziere. Und wie jedes andere Objekt kann sich das laufend ändern. Wenn ich Änderungen explizit mitbekommen will, dann nehme ich KVO.

Wenn Du mir dann noch erklärst, wie dass dann auf Systemen vor 10.3 funktioniert?

Original von Tom9811
Um mir über deine Meinung klar zu werden, schau bitte mal auf die Graphik in dem Artikel. Bist du der Meinung, dass der Member owner dort, eine Kopie anlegen sollte? Oder meinst du dort auch, dass man eine Kopie machen sollte?

Wenn du der Meinung bist, dass dort eine Referenz richtig ist, dann verstehe ich nicht, warum du das bei irgendeinem String anders siehst. Das ist genauso irgendein Objekt.

Warum ich das bei einem String anders sehe, habe ich hier jetzt mehrfach begründet. Wenn Du diese Gründe nicht akzeptieren kannst, ist das in Ordnung. Wir haben da eben einen unterschiedlichen Programmierstil. Macht doch nichts, denn wir kommen ja wohl beide an unser jeweils selbst gestecktes Ziel.

Original von Tom9811
Wenn du der Meinung bist, dass dort ebenfalls die Address-Instanzen kopiert werden sollten, so verstehe ich nicht, warum.

Nein, der Meinung bin ich nicht. Habe ich hier auch nie behauptet.

Michael

Zitat:
Original von Michael
Der Entwickler einer Klasse sollte schon wissen, was in einem Objekt was ist.

Jetzt verstehe ich dich gar nicht mehr. _Du_ hast doch geschrieben, dass du _nie_ einen String referenzieren würdest!
...
Für _dich_ ist es doch gerade gleich, was geschieht!

BTW: Wir beide wissen nicht, was ein Entwickler mit einem String als Member macht.

Ich habe ehrlich gesagt ein wenig Probleme mit Deinen Gedankensprüngen. Wenn ich von Setter-Methoden für String-Instanzvariablen rede, dann bin ich doch mit der Implementierung einer Klasse beschäftigt. Wieso soll ich da nicht wissen, welche Eigenschaften diese Klasse hat?

So geht es mir auch.

Nochmal: Deine These ist es doch, dass du niemals Strings referenzieren, sondern immer kopieren würdest. Wen du das immer machst, dann ist es doch gleichgültig, was genau geschieht. Du machst es ja immer. Die Aussage "immer" oder "niemals" kann doch nicht von einer Bedingung abhängen.

Um zum Ausgangspunkt zurückzukehren: Du sagtest, du wüdest das niemals so machen. Du wusstest aber doch gar nicht, ich auch nicht, was der Programmierer da genau vor hatte. Denncoh warst du dir bereits sicher, dass du es nicht so machen würdest.

Also ist es doch so, dass DU keine Rücksicht darauf nimmst, was gewollt ist.

Zitat:
Original von Tom9811
Zitat:
Original von Michael
Und was machst Du mit solchen IDs? Ich habe keine Ahnung, was Du mir hiermit sagen willst.

Ich will damit sagen, dass es durchauss Fälle, ich meine sogar die Mehrzahl, gibt, indem Strings referenzen sind. Einen ID referenziere ich häufig.

Das Du diese ID referenzierst habe ich mir schon gedacht. Aber wie verwendest Du die dann? Was bringt mir das? Ich habe es immer noch nicht verstanden.

Ich verwende sie als Rumpf für ein Objekt, das noch nicht geladen worden ist. Ich möchte da natürlich jede Änerung (die allerdings selten sein wird) mitbekommen.

Ebenso referenzieren ständig Views ihre Models, auch die Strings. Copying lohnt sich hier vor allem dann, wenn ich _intern_ herumfummele und dies natürlich nicht nach außen traen will.

Aber referenzieren hat einfach schon den Vorteil, dass es Speicher spart und ich nicht ständig neue Kopien bei Änderungen anfertigen muss.

Zitat:
Original von Tom9811
Ich sehe das auch nicht so, dass ich Objekte setze. Das ist unser Grundunterschied. Ich setze Referenzen. Grundsätzlich basiert KVO, KVC, CB auf Referenzen.

Dann erkläre mir doch mal, warum das in der Demo nicht funktioniert. Ich habe da in der Demo zwei Referenzen auf einen String. Eine in der -awakeFromNib des AppControllers und eine dann im Personenobjekt. Wenn ich jetzt Deine Theorie richtig verstanden habe, dann sollte wenn ich über die Referenz in -awakeFromNib den String ändere, über KVO der PersonController das mitbekommen. Tut er aber nicht, sonst würde in den Vornamen-Feldern das gleiche stehen.

? Ich weiß nicht, was du mit Demo meinst. Aber, wenn du einen String doppelt referenzierst, also gerade keine Kopie anlegst, dann wid die Änderung auch ohn KVO doch automatisch vorgenomnen. Das ist doch das, was du gerade bemäkelst, ich aber für erwünscht halte?

Das KVO muss ich auf den Schlüssel des anderen haltenden Objektes setzen,. Nehmen wir also an, dass es um einen String firstname geht. Wenn AppController den bei Person beobachten will, dann muss er


machen. Er muss dies aber überhaupt nur machen, wenn er die Änderung explizit mitgeteilt wissen will. Normalerweise braucht er das gar nicht. Als Referenz ändert sich doch das referenzierte Objekt automatisch. Mit anderen Worten: Wenn jemand den Vornamen in person ändert, muss ich kene Angst haben, dass in dem AC der Name jetzt falsch steht. Ich brauche dafür auch keinen Observer. Wenn ich etwa den Vornamen als Präfix für weitere Strings verwende, steht er _automatisch_ immer irchtig. Ein



erzeugt mir _niemals_ inkonsitente Daten. Es wird _stets_, auch nach einer Änderung des Namens, den ich hier als Präfix verwende, der richtige String erzeugt.

Legst du hingegen eine Kopie an, so _musst_ du eine Observer installieren, weil du sonst die Änderung überhaupt nicht mitbekommst und inkonsistente Daten hast. Die Mehtode würde bei dir irgendeinen zusammengestezten String aus der Vergangenheit erzuegen, ganz sich er aber nicht den richtigen.

Das ist eigentlich sogar Absicht bei Zeigern. Man muss das freilich berücksichtigen.

Hier gibt es wohl eher ein "selector not recognized" Klar muss man das berücksichtigen und ich tue das eben gegebenenfalls auch im Setter. So ist nun mal mein Programmierstil.

*grrrr* In der Tat benutze ich wie Cocoa so gut wie nie NSMutableString. Das ist auch so eine Unsitte.

Du berücksichtigst das aber nicht, sondern "umgehst" das Problem. Ich habe ja auch nichts dagegen. Jeder so wie er will. Aber dir muss klar sein, dass du damit einfach Grundsätze verletzt, um das Problem zu beseitigen. Du musst dir die zusätzliche Arbeit aufhalsen, dein Model konsitent zu halten. Hierbei können Fehler unterlaufen.

Und, was für mich noch mehr zählt: Referenzen sind dafür gedacht, zu referenzieren. Das ganze System mit RC ist dazu da, dass du referenzierst.

Zitat:
Original von Tom9811
Ebendt(tm)! Deshalb solltest du auch nicht wegen eines Missverständnisses des Users über die Arbeitsweise von Pointern deine Implementation von Worker ändern.

Ich halte nichts davon, die Benutzung einer Klasse nur deswegen zu erschweren, nur weil ich alle Setter nach Schema F programmieren soll. Schau Dir mal -setString: von NSWindow an. Diese Methode macht auch eine Kopie vom Parameter, wenn man einen NSMutableString übergibt.

*seufz* Ich erleichtere die Benutzung der Objektes, ich erschwere sie nicht. Ich ermögliche es, dass ohne weiteren Aufwand alles konsitent bleibt.Nochmal: Es ist _Absicht_ und _gewollt_, dass sich das Objekt "für alle ändert". Wenn mir das szu gefährlich ist, weil ich gewisse Anforderungen stelle, dann muss ich KVO einsetzen. Du musst das jedesmal machen, damit deine Kopien erzeugt weden. Das ist nicht einfacher, das ist umständlicher, langsamer und speicherfressend.

Außerdem programierst du doch nach Schema F. Du sagtest doch "niemals."?!

Zitat:
Original von Tom9811
Um mir über deine Meinung klar zu werden, schau bitte mal auf die Graphik in dem Artikel. Bist du der Meinung, dass der Member owner dort, eine Kopie anlegen sollte? Oder meinst du dort auch, dass man eine Kopie machen sollte?

Wenn du der Meinung bist, dass dort eine Referenz richtig ist, dann verstehe ich nicht, warum du das bei irgendeinem String anders siehst. Das ist genauso irgendein Objekt.

Warum ich das bei einem String anders sehe, habe ich hier jetzt mehrfach begründet. Wenn Du diese Gründe nicht akzeptieren kannst, ist das in Ordnung. Wir haben da eben einen unterschiedlichen Programmierstil. Macht doch nichts, denn wir kommen ja wohl beide an unser jeweils selbst gestecktes Ziel.

Nein, das hast du nicht begründet. Sämtliche deiner Arhumente gelten für alle Refrenzen auf Objekte aller Klassen.

Welches Argument genau gilt nur für Strings?

Original von Tom9811
Nochmal: Deine These ist es doch, dass du niemals Strings referenzieren, sondern immer kopieren würdest. Wen du das immer machst, dann ist es doch gleichgültig, was genau geschieht. Du machst es ja immer. Die Aussage "immer" oder "niemals" kann doch nicht von einer Bedingung abhängen.

Um zum Ausgangspunkt zurückzukehren: Du sagtest, du wüdest das niemals so machen. Du wusstest aber doch gar nicht, ich auch nicht, was der Programmierer da genau vor hatte. Denncoh warst du dir bereits sicher, dass du es nicht so machen würdest.

Also ist es doch so, dass DU keine Rücksicht darauf nimmst, was gewollt ist.

Wenn ich eine Klasse sehe, die Vor- und Nachnamen verwaltet, kann ich mir einfach keine sinnvolle Anwendung vorstelle, dass man Vor- und Nachnamen am Setter vorbei verändern dürfen sollte. Im Gegenteil, ich sehe da eher ein Problem drin.

Original von Tom9811
Ich verwende sie als Rumpf für ein Objekt, das noch nicht geladen worden ist. Ich möchte da natürlich jede Änerung (die allerdings selten sein wird) mitbekommen.

Vielleicht bin ich ja doof, aber ich habe noch immer keine Vorstellung, wie das Modell dazu aussieht.

Original von Tom9811
Ebenso referenzieren ständig Views ihre Models, auch die Strings. Copying lohnt sich hier vor allem dann, wenn ich _intern_ herumfummele und dies natürlich nicht nach außen traen will.

Und wenn man seine Daten vernünftig kapseln will.

Original von Tom9811
Aber referenzieren hat einfach schon den Vorteil, dass es Speicher spart und ich nicht ständig neue Kopien bei Änderungen anfertigen muss.

Ob ich nun von einem NSMutableString eine Kopie im Setter anlege oder das vor der Übergabe erledigen muss, ist vom Speicherverbrauch identisch.

Original von Tom9811
? Ich weiß nicht, was du mit Demo meinst.

Ich habe hier einige Beiträge vorher ein kleines Demo-Projekt drangehängt.

Original von Tom9811
Aber, wenn du einen String doppelt referenzierst, also gerade keine Kopie anlegst, dann wid die Änderung auch ohn KVO doch automatisch vorgenomnen.

Nur warum bemerkt das Interface des Demo-Programms denn diese Änderung nicht? Schließlich beobachtet es doch das Person-Objekt. Nach Deiner Meinung kann das doch gar nicht passieren.

Original von Tom9811
Das KVO muss ich auf den Schlüssel des anderen haltenden Objektes setzen,. Nehmen wir also an, dass es um einen String firstname geht. Wenn AppController den bei Person beobachten will, dann muss er

In der Demo will AppController aber nicht Person beobachten. Das Inteface beobachtet Person, bekommt aber eine Änderung nicht mitgeteilt, weil Person selber nichts merkt und plötzlich sogar die internen Daten inkonsistent sind.

Original von Tom9811
erzeugt mir _niemals_ inkonsitente Daten. Es wird _stets_, auch nach einer Änderung des Namens, den ich hier als Präfix verwende, der richtige String erzeugt.

Schau Dir das Demoprojekt wirklich mal an. Dann siehst Du, wie ein Datenobjekt in sich inkonsistent werden kann, weil es Änderungen an sich selbst nicht mitbekommt. Oder soll ein Objekt jetzt auch noch seine eigenen Instanzvariablen observieren?

Original von Tom9811
Du berücksichtigst das aber nicht, sondern "umgehst" das Problem.

Ob nun "berücksichtigen" oder "umgehen". Ist mir egal, wie Du das bezeichnest, so lange mein Programm das macht, was es soll.

Original von Tom9811
Ich habe ja auch nichts dagegen. Jeder so wie er will. Aber dir muss klar sein, dass du damit einfach Grundsätze verletzt, um das Problem zu beseitigen.

Ich fahre damit sehr gut. Jeder Grundsatz hat auch Ausnahmen. Mein Grundsatz, Value-Objekte in der Regel zu kopieren, hat auch Ausnahmen. Ja, ich weiß, ich habe am Anfang niemals geschrieben, geschenkt. Ich habe da über die Formulierung nicht großartig nachgedacht.

Original von Tom9811
Du musst dir die zusätzliche Arbeit aufhalsen, dein Model konsitent zu halten. Hierbei können Fehler unterlaufen.

Ich sehe da keinen Mehraufwand. Im Gegenteil, wenn ich hier so einige Codeschnipsel von Dir sehe, habe ich eher weniger Aufwand in der Benutzung meiner Objekte zu treiben.

Original von Tom9811
Und, was für mich noch mehr zählt: Referenzen sind dafür gedacht, zu referenzieren. Das ganze System mit RC ist dazu da, dass du referenzierst.

Ja, und die Methode -copy ist dazu da, wenn nötig Kopien zu machen.

Original von Tom9811
*seufz* Ich erleichtere die Benutzung der Objektes, ich erschwere sie nicht. Ich ermögliche es, dass ohne weiteren Aufwand alles konsitent bleibt.Nochmal: Es ist _Absicht_ und _gewollt_, dass sich das Objekt "für alle ändert". Wenn mir das szu gefährlich ist, weil ich gewisse Anforderungen stelle, dann muss ich KVO einsetzen.

Die Antwort, wie das auf Systemen vor 10.3 funktionieren soll, bist Du mir schuldig geblieben. Wenn sich Programmiergrundsätze mit jeder Mac OS X Version ändern, dann kann man Mac OS X als Entwicklerplattform knicken.

Original von Tom9811
Du musst das jedesmal machen, damit deine Kopien erzeugt weden. Das ist nicht einfacher, das ist umständlicher, langsamer und speicherfressend.

Nein, ich muss es nicht jedesmal machen, weil ich nur Value-Objekte kopiere. Ich muss aber im Gegensatz zu Dir nicht meine eigenen Instanzvariablen für Value-Objekte observieren.

Original von Tom9811
Außerdem programierst du doch nach Schema F. Du sagtest doch "niemals."?!

Man kann sich an einem Wort auch ewig hochziehen. Ich denke, ich habe im laufe der Diskussion meinen Standpunkt präzisiert.

Original von Tom9811
Nein, das hast du nicht begründet. Sämtliche deiner Arhumente gelten für alle Refrenzen auf Objekte aller Klassen.

Welches Argument genau gilt nur für Strings?

Strings sind in der Regel (Ausnahmen bestätigen die Regel!) Value-Objekte. Ich habe hier Code-Schnipsel, ein Beispiel-Projekt und aus einem Buch zitiert. Wenn das alles keinerlei Bedeutung für Dich hat, dann können wir die Diskussion jetzt beenden.

Michael

Ich glaube, wir kommen zu keinem gemeinsamen Nenner. Nur noch, was unser Grundunterschied zu sein scheint:

- Ich halte eine Referenz. Diese Referenz ist gekapselt. Dass heißt nicht, dass das referenzierte Objekt von mir gekapselt ist. Auf dieses Objekt verweisen vielleicht 7 Leute. Es gibt da keine Kapsel des Verweises. Bei dir sind alle Objeke Verweise intrinsisch.
Das setzen einer Referenz ist also gekapselt. In der Tat beschrieb ich schon, dass es ganz natürlich ist, dass sich das referenzierte Objekt, wass ja wiederum eine neue Kapsel ist, siich inhaltlich ändern kann. Deshalb gibt es doch den ganzen Scheiß KVO,KVC,RC,CB. Um das zu kontrollieren. Dazu muss ich aber keine Kopie anlegen. Und selbstverständlich hältst du bei einem mehrfach referenzierten String-Objekt jedesmal eine Kopie.

Du behandelst Strings halt als Skalare, nicht als Objekte. Ansonsten verstehe ich dich so, dass du auch keine Kopie machen würdest?

- Richtig, es gibt copy zum kopieren. Auf Kopie baut aber nicht ein ganzes Programmiersystem einschl. RC auf. oC implementiert aus vorgenannten Gründen RC, nicht CC.

- Das Demo-Projekt hatte ich übersehen, sorry. Ich schaue es mir mal an. Wenn es auf dem gleichen Prinzip baisert, wie dein tempStriing-Beispiel, dann nochmal: Du merzt mit einem Fehler einen anderen aus. Du kämst doch auch bei keinem anderen Objekt auf diese Idee?

++ Update
Ah, jetzt komme ich vielleicht auf den Trichter.

Stelll dir vor, die Klasse Address würde als Instanz-Methode -clear implementieren. Dann könnte ich auch "am Setter vorbei" eine Instanz verändern. Ich kann das überhaupt immer, weil ich die Member-variablen stets selbst setzen kann. Merkt keiner etwas von.

_Das_ ist der Fehler. Den gleiche ich nicht aus. Ich mache so etwas erst gar nicht.

Original von Tom9811
Ich glaube, wir kommen zu keinem gemeinsamen Nenner.

Scheint mir auch so. Aber davon geht die Welt nicht unter. :]

Original von Tom9811
Bei dir sind alle Objeke Verweise intrinsisch.

Nein, nicht alle Objekte. Bitte unterstelle mit nicht etwas, was ich nicht behauptet habe.

Original von Tom9811
Du behandelst Strings halt als Skalare, nicht als Objekte. Ansonsten verstehe ich dich so, dass du auch keine Kopie machen würdest?

Richtig, außer ein spezifischer Fall (Ausnahmefall!) erfordert es, dies nicht zu tun.

Original von Tom9811
++ Update
Ah, jetzt komme ich vielleicht auf den Trichter.

Stelll dir vor, die Klasse Address würde als Instanz-Methode -clear implementieren. Dann könnte ich auch "am Setter vorbei" eine Instanz verändern. Ich kann das überhaupt immer, weil ich die Member-variablen stets selbst setzen kann. Merkt keiner etwas von.

_Das_ ist der Fehler. Den gleiche ich nicht aus. Ich mache so etwas erst gar nicht.

Na na na, Du wirst doch wohl nicht von Deinem eigenen Pfade abgehen und in der Implementation der Methode -clear direkt die Instanzvariablen löschen? Du machst doch sonst alles über die Accessor-Methoden.

Michael

Zitat:
Original von Tom9811
Ich glaube, wir kommen zu keinem gemeinsamen Nenner.

Scheint mir auch so. Aber davon geht die Welt nicht unter.

Ich weiß nicht, ich weiß nicht. Hier wackelt es ein bisschen und der Himmel ist so seltsam rot. Ist das die Apokalypse?

Zitat:
Original von Tom9811
Du behandelst Strings halt als Skalare, nicht als Objekte. Ansonsten verstehe ich dich so, dass du auch keine Kopie machen würdest?

Richtig, außer ein spezifischer Fall (Ausnahmefall!) erfordert es, dies nicht zu tun.

Wenn du das mal gleich gesagt hättest, hätten wir uns 23712037219837 Beiträge ersparen können. Ich hatte auch das schonmal gesagt, du hattest aber nicht entsprechend geantwortet. Oder habe ich das wieder überlesen?

Zitat:
Original von Tom9811
Bei dir sind alle Objeke Verweise intrinsisch.

Nein, nicht alle Objekte. Bitte unterstelle mit nicht etwas, was ich nicht behauptet habe.

Touché! Ich meinte alle String-Objekte (bis auf Ausnahmen).

Zitat:
Original von Tom9811
++ Update
Ah, jetzt komme ich vielleicht auf den Trichter.

Stelll dir vor, die Klasse Address würde als Instanz-Methode -clear implementieren. Dann könnte ich auch "am Setter vorbei" eine Instanz verändern. Ich kann das überhaupt immer, weil ich die Member-variablen stets selbst setzen kann. Merkt keiner etwas von.

_Das_ ist der Fehler. Den gleiche ich nicht aus. Ich mache so etwas erst gar nicht.

Na na na, Du wirst doch wohl nicht von Deinem eigenen Pfade abgehen und in der Implementation der Methode -clear direkt die Instanzvariablen löschen? Du machst doch sonst alles über die Accessor-Methoden.

Eben würde ich nicht. Deshalb gibt es bei mir auch keinen temp*. Deshalb lege ich auch keine Kopien an. Richtig.

Original von Tom9811
Wenn du das mal gleich gesagt hättest, hätten wir uns 23712037219837 Beiträge ersparen können. Ich hatte auch das schonmal gesagt, du hattest aber nicht entsprechend geantwortet. Oder habe ich das wieder überlesen?

Ich habe es zumindest versucht in der Diskussion rüber zu bringen. Ist wohl nicht so gelungen.

Michael

Du hast hierauf gar nicht geantwortet, sondern darauf verwiesen, dass Worker kein String sei!?

Original von Tom9811
Du hast hierauf gar nicht geantwortet

Worauf habe ich nicht geantwortet? Ich kann nicht ganz folgen. Ich habe noch mal nachgeschaut. Direkt in dem Beitrag, nachdem ich das "böse" Wort niemals erwähnt hatte, habe ich eigentlich eine klare Aussage gemacht.

Michael

Auf mein erstes erwähnen von "Skalar". War aber auch erst gestern.

Ach so. Ich dachte, das wäre schon klar gewesen.

Michael

Ich habe mir gerade dein Demo angeschaut.

Sorry, aber nochmal: Der Fehler ist die doppelte Verzeigerung, die du gar nicht willst. Diesen Fehler gleiche ich nicht durch einen erneuten Fehler aus- weder in der Theorie noch in der Praxis.

Wer zweit Pointer auf ein Objekt setzt und meint, dass die Änderung des Inhaltes des einen Pointers auf den anderen ohne Einfluss bleibt, arbeitet grundsätzlich falsch mit Pointern.

Das ist aber auch nichts Neues, sondern seit C bekannt. Auch in Pascal kannst du ähnlichen Kram programmieren. Mit Settern und Gettern hat das auch nichts zu tun. Das ist schlicht die falsche Verwendung von Zeigern.

Original von Tom9811
Ich habe mir gerade dein Demo angeschaut.

Sorry, aber nochmal: Der Fehler ist die doppelte Verzeigerung, die du gar nicht willst. Diesen Fehler gleiche ich nicht durch einen erneuten Fehler aus- weder in der Theorie noch in der Praxis.

Also, wenn ich eine Klasse so definiere, dass man dieser Klasse einen NSMutableString übergeben darf, diesen dann weiter verarbeiten darf, ohne dass sich das Objekt verändert, dann ist das kein Fehler. Es ist ja wohl erlaubt Objekte, die per Pointer übergeben werden, so zu behandeln, wie man es selbst definiert. Ein Programm, das so funktioniert, wie es funktionieren soll ist nicht fehlerhaft.
Wer versichert Dir denn, dass es niemals vorkommen kann, das eine Settermethode für NSString einen NSMutableString übergeben bekommt? Manchmal weiß man ja gar nicht, dass man von einer Methode einen NSMutableString zurück bekommt.

Michael

Doch, ich halte das für bereits dort fehlerhaft.

Wenn ich einen Pointer weitergebe, kann damit alles passieren Darüber muss ich mir klar sein. Auch schon in C.

Wenn ich einen Pointer weitergebe und weiterhin mit dem Object arbeiten möchte, so kann ich das ja selbst sehen und übergebe dann eben eine Kopie. Aber da muss ich auch nur dann machen:



Wenn ich das nachträglich ein- ode ausbaue, so kann ich das Verhalten in der obigen Routine auch nur in der obigen Routine ändern: Passt!

Wenn der setter der benutzten Klasse Änderungen vornehmen will, die wiederum für ihn privat bleiben sollen, so muss sich eben auch die benutzte Klasse darum kümmern und in ihrem Setter eine Kopie anfertigen. Wenn sich da etwas ändert, merkt niemand anderes etwas davon: Passt!

BTW: _Du_ machst ds übrigens richtig mit der Kopie (autorelease+copy). In den Apple-Sourcen findet man zuweilen release+copy, was übelst ins Auge gehen kann.

Du bemerkst doch das Problem stätestens dann, wenn aus einem value wieder eine Referenz wird und umgekehrt. Obwohl das eigentlich ein gekapseltes Implementierungsdetail ist, hat es Auswirkungen nach außen. Und woher weißt du überhaupt, ob es ein Value-Setter ist und du ungefährlich den Pointer weiter verwenden darfst? Dazu müsstest du doch jedesmal die Doku zu der Klasse lesen. Dranstehen tut es nicht.

Ja, ich weiß nicht, ob ich ein Mutable übergeben bekomme. Deshalb sage ich ja: Jeder ist für seine Änderungen selbst verantwortlich. Ich gehe davon immer aus! Also, wer Pointer weggibt oder empfängt, soll nichts ändern oder eine Kopie anfertigen. (Es sei denn, er möchte gerade so etwas machen.)

Also, ich halte meine Lösung für besser gekapselt. Vor allem: Ich gewinne dadurch ja noch Speicher und Geschwindigkeit.

BTW: Ich möchte mich bei dir für die Diskussion herzlich bedanken. Mir sind wieder neue Aspekte besser klar geworden. Das ist das schöne an einem Forum.