NSString ECHTE Kopie

  • warum, was soll das problem sein?

    1. positionen der selektierten objekte kennst du ja (NSIndexSet)
    2. die menge der selektierten elemente kennst du auch (count vom NSINdexSet)
    3. die insert-position kennst du auch

    also gehst du einfach her und packst alle objekte die mittels des NSIndexSet zu finden sind an die insert-position. Dann gehst du alle indexe im index-set durch und wenn sie vor der insert-position sind, dann löscht du genau den index, andernfalls eben den index plus den count vom indexset - fertig.

  • Original von johannesauer
    @hns
    Das würde auf jeden Fall klappen. Aber warum nötigt mich cocoa zu diesem umweg? Alle anderen objekte werden ja durch ihre speicheradressen unterschieden, nur NSString scheint da ne Ausnahme zu machen.
    Nein. Objekte werden durch -isEqual: unterschieden. D.h. alle bei denen isEqual wahr ist gelten (z.B. bei der Suche des Index in einem Array) als gleich. Ob sie nun die gleiche Speicheradresse haben oder nicht.

    Wenn Dir das komisch vorkommt: zwei int-Werte sind gleich wenn sie den gleichen Wert haben, auch wenn sie in verschiedenen Registern oder Speicheradressen liegen...

    Auch NSNumber macht eine Optimierung ([NSNumber numberWithInt:5] liefert immer die gleiche Speicheradresse für ein Objekt "5"; auch wenn man die 5 aus einer anderen NSNumber mittels intValue bestimmt hat).

    Zum D&D-Problem ist es m.E. grundfalsch das Löschen anhand der Inhalte machen zu wollen. Das einzige was relevant ist sind die Indizes (siehe Beitrag gritsch). Dann geht das später auch wenn man nicht Strings sondern Numbers oder Bilder oder wasweissich verschieben will.

    -- hns

  • Hi,

    die Gleichheit von Objekten wird durch -isEqual: unterschieden, nicht die Identität. Zwei Objekte sind gleich, wenn sie dieselbe Information darstellen, indentisch müssen Sie dafür aber nicht sein. Identisch sind Sie erst wenn es nichts mehr gibt, das Sie unterscheidet. Und genau das ist das Problem. Cocoa lässt mich in der hinsich nur mit Gleichheit arbeiten, nicht aber mit Identität. Nur weil Dinge dieselbe Information enthalten, müssen Sie ja nicht gleich sein. Und genau das nimmt Cocoa in diesem Fall an. Gegen Optimierung habe ich ja nichts, aber in diesem Fall nimmt Sie Möglichkeiten. Aber es macht keinen Sinn sich gegen das Framework zu stemmen, da muss ich ne andere Lösung finden...

    Über den Index zu gehen finde ich nicht so schön, der könnte sich ja ändern wenn ich wieder drauf zugreife. Ein eindeutiger Identifier wäre die beste Lösung, und das ist eben z.B. die Speicheradresse (jedes Objekt, und nur dieses, hat genau eine Speicheradresse).

    Ich werkel mal noch ein wenig rum und melde mich, sobald ich ne schöne Lösung habe...

    Gruss und Danke für eure Zeit,
    Johannes

  • Ich werkel mal noch ein wenig rum und melde mich, sobald ich ne schöne Lösung habe...
    Bin schon gespannt, was passiert, wenn die Objekte Deines Arrays mal kein NSCopying unterstützen. Bei NSManagedObjects wird's dann richtig nett.

    ne erst nach dem drop, aber das ist ja gerade das Problem. Nach dem drop sind die Objekte doppelt im array drin, und nun muss ich die "alten" loswerden.
    Das ist sozusagen ein durch Deinen Ansatz selbst geschaffenes Problem.

    Es bleibt spannend... :D

    No.

  • Das ist sozusagen ein durch Deinen Ansatz selbst geschaffenes Problem.


    Das stimmt! Aber mein Ansatz ist richtig, wenn man davon ausgeht, das es zwei Objekte geben kann, die Gleich, aber nicht Identisch sind. Nur macht Cocoa das eben nicht...

    Bin schon gespannt, was passiert, wenn die Objekte Deines Arrays mal kein NSCopying unterstützen. Bei NSManagedObjects wird's dann richtig nett.


    Bei CD gibts doch nen unique Object Identifier oder? Das löst ja das Problem!

  • Original von johannesauer
    Das ist sozusagen ein durch Deinen Ansatz selbst geschaffenes Problem.


    Das stimmt! Aber mein Ansatz ist richtig, wenn man davon ausgeht, das es zwei Objekte geben kann, die Gleich, aber nicht Identisch sind. Nur macht Cocoa das eben nicht...

    Bin schon gespannt, was passiert, wenn die Objekte Deines Arrays mal kein NSCopying unterstützen. Bei NSManagedObjects wird's dann richtig nett.


    Bei CD gibts doch nen unique Object Identifier oder? Das löst ja das Problem!


    welchen sinn soll es ergeben einen konstanten "wert" unendlich mal in den speicher zu packen anstelle nur einen verweis auf das "original"?

  • Bei CD gibts doch nen unique Object Identifier oder? Das löst ja das Problem!
    Du kopierst doch zuerst und dann suchst Du die Dubletten, wenn ich Dich richtig verstehe. Zu dem ersten Schritt davon: Schick' mal einem NSManagedObject ein copy und schau, was passiert.

    Nur macht Cocoa das eben nicht...
    Warum programmierst Du dann mit Cocoa?

    Ich bin hier offenbar nicht der einzige, der meint, Du solltest Deinen Ansatz überdenken. Das solltest Du bedenken, denke ich.

    No.

  • welchen sinn soll es ergeben einen konstanten "wert" unendlich mal in den speicher zu packen anstelle nur einen verweis auf das "original"?


    Damit man Objekte nicht nur anhand ihrer Gleicheit, sondern ihrer Identität unterscheiden kann.
    Das braucht man relativ selten, aber das Cocoa einem die Möglichkeit nimmt finde ich...doof ;)

    Wenn du eine Datei auf deinem System kopierst, dann ist die Information dieselbe, aber trotzdem sind es 2 Objekte. Das macht ja auch Sinn, weil man ja die eine ändern kann, ohne das die Andere sich ändert. Aber nur weil man ein Objekt nicht mehr ändern kann, heisst es ja nicht, das es davon kein 2tes geben kann, oder besser: das es in keinem Fall einen Sinn haben könnte, die Beiden zu unterscheiden. Aber den kann es haben (z.B. in meinem Fall). Das ist ne reine Optimierung und hat in den meisten Fällen keine negativen Auswirkungen, nur in diesem Fall eben schon.

    Gruss,
    Johannes

  • du irrst dich - cocoa nimmt dir nicht die möglichkeit sondern utnerscheidet da eben zwischen mutable und immutable. wenn du eine neue adresse haben willst musst du eben mutable verwenden - so einfach ist das.

    dein vergleich mit der datei auf der platte hinkt (und du hast sogar selbst angegeben warum). Wenn man dateien nicht bearbeiten könnte, dann würde man sie auch nicht 2 mal auf die platte packen bei einer kopie (siehe auch "ln" und hardlink;-))

  • warum programmierst Du dann mit Cocoa?


    Naja, nur weil ich für den Mac programmieren will, heisst das ja nicht, das ich alles an Cocoa toll und richtig finde. Aber ich will keinen Glaubenskrieg über Cocoa auslösen, das meiste ist ja auch schön...

    Ich bin hier offenbar nicht der einzige, der meint, Du solltest Deinen Ansatz überdenken. Das solltest Du bedenken, denke ich.


    Das stimmt, mein Ansatz ist in Verbinding mit Cocoa nicht der Richtige. Aber wir schweifen ab, eigentlich suche ich ja nach einer Lösung für das Problem, und nicht nach der Begründung, warum es so ist. Ich überlegt mir mal was Anderes...

    Gruss,
    Johannes

  • du irrst dich - cocoa nimmt dir nicht die möglichkeit sondern utnerscheidet da eben zwischen mutable und immutable. wenn du eine neue adresse haben willst musst du eben mutable verwenden - so einfach ist das.


    Die sind dann eben mutable.

    dein vergleich mit der datei auf der platte hinkt (und du hast sogar selbst angegeben warum). Wenn man dateien nicht bearbeiten könnte, dann würde man sie auch nicht 2 mal auf die platte packen bei einer kopie (siehe auch "ln" und hardlink;-))


    Nein er hinkt eben nicht !
    Alle gehen davon aus, das es keinen Sinn machen kann, unveränderbare Objekte mit gleichem Inhalt unterscheiden zu können. Aber das kann eben Sinn machen ;)

  • Original von johannesauer
    du irrst dich - cocoa nimmt dir nicht die möglichkeit sondern utnerscheidet da eben zwischen mutable und immutable. wenn du eine neue adresse haben willst musst du eben mutable verwenden - so einfach ist das.


    Die sind dann eben mutable.

    dein vergleich mit der datei auf der platte hinkt (und du hast sogar selbst angegeben warum). Wenn man dateien nicht bearbeiten könnte, dann würde man sie auch nicht 2 mal auf die platte packen bei einer kopie (siehe auch "ln" und hardlink;-))


    Nein er hinkt eben nicht !
    Alle gehen davon aus, das es keinen Sinn machen kann, unveränderbare Objekte mit gleichem Inhalt unterscheiden zu können. Aber das kann eben Sinn machen ;)


    stehst du aufm schlauch oder was?

    genau das ist doch der grund dass es NSString und NSMutableString gibt. Das eine ist eben konstant und hat immer die selbe adresse und das andere ist nicht konstant, kann verändert werden und es hat folglich jedesmal eine eigene adresse. OB du dann den inhalt veränderst oder nicht liegt ja an dir, du hast aber eine kopie des gesamten inhaltes und folglich auch eine neue adresse.

    das mit dem file-system hinkt, kannst du fragen wen du willst!

  • warum SUCHST du noch?

    wir haben dir doch 2 perfekte lösungen genannt:

    a) mit den indexen zu arbeiten


    Das klappt nur unter bestimmten Umständen. Wenn die nicht in Reihe sind z.B. nicht.

    b) mutable-strings zu verwenden was eigentlich genau das tut was du eigentlich von NSString haben willst (es dort aber keienn sinn machen würde und einfach falsch wäre)


    Das ist wohl die beste Lösung.


    Gruss & Danke,
    Johannes

  • Original von johannesauer
    bitte?


    Entschuldige, du hast Recht, das klappt immer. Das ist die beste Lösung.

    Warum das alle anfangen persöhnlich zu nehmen verstehe ich nicht...

    Gruss,
    Johannes


    nimmt ja niemand persönlich aber du sperrst dich einfach. du erwartest von einer klasse ein verhalten für das apple extra eine andere klasse erstellt hat...