Methoden, Klassen, usw.

Peter Maurer

Pommerscher Krummstiel
Registriert
16.03.04
Beiträge
3.077
Ach, Ihr verwendet so eine Notation:

Code:
[meinObjekt machWasMitDiesemParameter: haensel
                             undJenem: gretel
                       undDemHierAuch: ofen];
Lieg' ich da richtig? Dann versteh' ich das Problem mit den Doppelpunkten. Und ja, ich geb's zu: Ich kenn' das Buch nicht. Hab's aber trotzdem schon mal jemandem empfohlen. :D
 
Zuletzt bearbeitet:

pepi

Cellini
Registriert
03.09.05
Beiträge
8.740
Ich hatte das schon absichtlich in Anführungszeichen gesetzt. So geht das leider nicht:, weil etwa die Doppelpunkte untereinander stehen.
IIRC hatte ich Fettschrift ausprobiert bei der Vorauflage. Da ging das nicht. Das war natürlich bei dem Zeichensatz aus der Vorlage, die ich bekommen hatte. Ich weiß nicht, ob es derselbe ist.

Aber wie gesagt: Darüber muss man sicher noch reden. Das ist zwar überhaupt nicht schlimm, aber irgendwie doch störend. Und wir reden hier über Maccies. (Bei Linuxern würde ich mir darüber keine Gedanken machen und durchgängig plain Text befürworten. ;))
Soweit mir meine Augen keinen Streich spielen ist die Schrift die für Code verwendet wird auch leider nicht unproportional. Somit ist jegliche Mühe irgendeine gscheite Einrückung, oder Ausrichtung zu bekommen ohnehin vergebens. Die Layoutbeauftragten sollten es eigentlich schaffen eine unproportionale Schrift zu wählen deren normaler und fetter Schnitt die selbe Laufweite haben. Dann klappts auch mit den Doppelpunkten. :)
Gruß Pepi
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Soweit mir meine Augen keinen Streich spielen ist die Schrift die für Code verwendet wird auch leider nicht unproportional. Somit ist jegliche Mühe irgendeine gscheite Einrückung, oder Ausrichtung zu bekommen ohnehin vergebens. Die Layoutbeauftragten sollten es eigentlich schaffen eine unproportionale Schrift zu wählen deren normaler und fetter Schnitt die selbe Laufweite haben. Dann klappts auch mit den Doppelpunkten. :)
Gruß Pepi

Das kann sogar sehr gut sei. Mir ist auch mal so etwas aufgefallen.

Ja, das bekommt die hin. Man muss es halt absprechen, wie es sein soll. Das sollte wirklich kein unlösbarer Problem darstellen.

@Peter: Ja, so sollte es sein. Jetzt schaue ich selbst noch mal nach. *g*

Also, dicktengleich müsste es eigentlich sein, etwa Seite 178. Dort sind zwei Strings untereinandre mit der gleichen Länge. Doppelpunkt kann ich nicht beurteilen, da ich nur umgebrochene Stellen finde.
 

zirpl

Golden Delicious
Registriert
28.09.07
Beiträge
10
Hallo liebe Leut'!

Meinen Einstieg in die Cocoa Entwicklung fand ich vor ungefähr drei Jahren mit "Cocoa Programming for Mac OS X" von Aaron Hillegass. Weiters haben mich bei meinen ersten Schritten Steven Kochans "Programming in Objective-C" und "Core Mac OS X and Unix Programming" von Aaron Hillegass und Mark Dalrymple begleitet. Obwohl diese Bücher mittlerweile schon recht alt sind, kann ich diese Kombination jedem empfehlen, der am Mac programmieren lernen will.

Da ich jedoch seit etwa zwei Jahren keine Zeit für irgendwelche Cocoa-Projekte gefunden hatte, dachte ich, es sei keine schlechte Idee mein Wissen mal wieder aufzufrischen. Wenn man dabei auch noch deutschsprachige Autoren unterstützen kann - umso besser.

Ich habe mir also "Objective-C und Cocoa" gekauft. Die ersten fünf Kapitel habe ich nur überflogen, da es für mich hier nicht sonderlich viel zu lernen gab. Ab Kapitel 6 hab ich die Beispiele mitgemacht.

Das GridView Beispiel fand ich recht nett, wenn vielleicht auch für manchen Einsteiger zu umfangreich. Hier wären zumindest die schon angesprochenen Hervorhebungen für Code-Änderungen recht wichtig. Die Fehler in diesem Kapitel könnte man vielleicht noch als "Feature" abtun. Wenn man konzentriert bei der Sache ist, findet man sie auch ohne Probleme. Trotzdem - schön ist das nicht und die Tatsache, dass im Beispiel acceptsFirstResponder: fehlt, ist für einen Anfänger schon schwer zu finden. Errata hin oder her.

Außerdem ist es auch sehr unschön, dass die meisten Methoden nicht im Header deklariert sind. Da das Beispiel ohnehin schon sehr groß ist, hätte man vielleicht an dieser Stelle auch zeigen können, wie man über Categories private Methoden in Objective-C implementiert. Dann würde auch beim Übersetzen nicht so lange nach Abhängigkeiten gesucht werden und man hätte die Methoden trotzdem nicht im Header bekannt machen müssen.

Was mir aber besonders bitter aufgestoßen ist, ist die Verwendung von einleitenden Underscores bei Attributnamen. Diese sind aus gutem Grund Apple vorbehalten! Was wäre zum Beispiel, wenn Apple in einer der Superklassen plötzlich ein gleichnamiges Attribut einführt? Weiters führt das zu Problemen beim Key-Value Coding und bei Bindings. Das ist sehr schlechter Programmierstil! Unter "Key-Value Coding Fundamentals" kann man bei Apple folgendes lesen:

"Keys must use ASCII encoding, begin with a lowercase letter, and may not contain whitespace."

Natürlich habe ich mir nicht jeden Fehler und jede Ungereimtheit gemerkt die ich gefunden habe, aber ab Kapitel sieben begann es dann richtig übel zu werden. Ein schönes Beispiel findet man auf den Seiten 338 und 339. Die Fehler dort fallen sogar einem blinden Lektor mit Krückstock auf. Weiters fällt auf, dass man hier plötzlich von den selbst gemachten Empfehlungen (zB Underscore-Notation) abgeht. Dafür werden plötzlich Attributnamen mit Großbuchstaben am Anfang verwendet (zB Seite 353). Das ist ein "stilistisches Schwerverbrechen" und führt ebenfalls zu Problemen beim Key-Value Coding.

Man quält sich also durch den fehlerhaften und schlecht gelayouteten Code und denkt, es könne nicht mehr schlimmer werden.

In Kapitel 8 geht es dann aber noch weiter bergab. Nicht nur, dass die Erläuterungen zum Thema Drag & Drop nicht ganz richtig sind - es funktioniert auch das Beispiel nicht. Nicht einmal das Projekt, welches man bei cocoa:ding herunter laden kann, funktioniert.

Das Beispiel lässt sich nicht ohne Warnings übersetzen, da darauf vergessen wurde, dass die überschriebenen Methoden auch etwas zurück geben müssen. Nebenbei frage ich mich, wie ein Anfänger verstehen soll, weshalb an einer Stelle unsigned int als Rückgabewert angegeben wird. Klar ist NSDragOperation ein unsigned int, aber unschön ist es trotzdem. Ach ja - bei performDragOperation: wird statt eines Booleans NSDragOperationCopy zurück gegeben. Die Methode initWithFrame: wird auch nicht aufgerufen. Das funktioniert nämlich nur in Klassen, die man direkt von NSView hergeleitet hat. Statt dessen sollte das Setup in awakeFromNib: passieren. Im Grunde würde das in diesem Fall nicht einmal was an der Funktionalität ändern, da registerForDraggedTypes: nicht notwendig ist um das Beispiel zum Laufen zu bringen. Einige standard-Typen sind nämlich schon von Haus aus registriert. Wollte man das Dragging tatsächlich auf TIFF einschränken, müsste vor registerForDraggedTypes: noch ein unregisterDraggedTypes: erfolgen. Im Gegensatz zu den Angaben im Text muss aber draggingEntered: unbedingt implementiert werden.

In einem so kurzen Beispiel derart viele Fehler einzubauen ist schon ein kleines Kunststück. Typographische Fehler sind im Vergleich dazu wirklich vernachlässigbar.

Ich habe an dieser Stelle aufgehört weiter mit dem Buch zu arbeiten. Meine Zeit ist mir hierfür einfach zu wertvoll. Ich halte dieses Werk für eine ziemlich große Schlamperei und es reicht sicher nicht, sich hier nur auf Lektoren oder auf den Verlag hinaus zu reden. Der Verlag kann sicher nichts dafür, dass offensichtlich nicht einmal die herunterladbaren Beispiele funktionieren.

Meiner bescheidenen Ansicht nach ist Softwareentwicklung eine Tätigkeit, bei der Sorgfalt ganz oben steht. Klar passieren Fehler - keine Frage. Es heißt ja nicht jeder Donald E. Knuth. ;) In dieser Häufigkeit habe ich sie aber noch in keinem einzigen Fachbuch gefunden. Ich rate jedem, der ernsthaft daran interessiert ist in die Mac OS X Programmierung einzusteigen, die Finger von diesem Buch zu lassen und fände es auch fair den Kunden gegenüber, die aktuelle Auflage vom Markt zu nehmen. So wenig sind fünfzig Euro auch wieder nicht. Bei jedem anderen Produkt hätte ich das Geld zurück verlangt.

Es gibt im Buch auch ein Kapitel "Extreme programming". Obwohl dieser Begriff hier in einem anderen Kontext verwendet wird, möchte ich doch auch auf Kent Beck verweisen. Er fordert unter anderem den Mut ein, etwas wegzuwerfen, wenn man sich zu sehr verfahren hat. Das ist oft sinnvoller und effizienter als eine Korrektur. Das trifft sicher nicht auf das ganze Buch zu, aber manchen Kapiteln täte es sicher gut, wenn sie komplett neu geschrieben werden würden. Ich glaube auch, dass es sinnvoller sein könnte ein paar Kapitel weg zu lassen, als an anderen Stellen, an denen es wirklich interessant werden würde, auf die Apple-Dokumentation zu verweisen.

Ich beschäftige mich seit den 80er Jahren mit Software-Entwicklung und habe unter anderem schon unter dem klassischen Mac OS programmiert. Anfangs noch mit MPW, später mit Think C und schließlich mit CW in C++ mit PowerPlant. Später habe ich mich von der Desktop Entwicklung abgewendet und viele Jahre lang WebObjects Anwendungen in Java geschrieben. Ich denke also, dass ich mir ein gewisses Grundverständnis in Sachen Softwareentwicklung angeeignet habe.

So. Ich hab mir jetzt sicher nicht viele Freunde gemacht. Daher ein paar Worte der Versöhnung am Schluss. Deutschsprachige Fachliteratur zur Mac Entwicklung ist sehr begrüßenswert, verlangt aber von den Autoren und auch vom Verlag sehr viel Mut. Außerdem ist auch eine gehörige Portion Enthusiasmus notwendig, da wir alle wissen, dass man mit so einem Projekt nicht reich werden wird. Da ich Amins Beiträge aus dem Mac OS X Entwicklerforum kenne, schätze ich auch seine fachliche Kompetenz sehr. Das Problem dieses Buches ist sicher nicht mangelndes Fachwissen der Autoren, sondern das offensichtliche Fehlen von Qualitätsmanagement. Die Ursache hierfür ist sicher mehr beim Verlag, als bei den Autoren zu suchen.

Trotzdem kann man meiner Ansicht nach die Autoren nicht ganz aus der Pflicht entlassen. Das Buch hätte riesiges Potential, was leider verschenkt wurde. Etwas mehr Sorgfalt hätte dem Werk sehr gut getan. Ich hoffe, dass ich aufgrund dieses Beitrags nicht zur unerwünschten Person im Entwicklerforum oder hier geworden bin und auch darauf, dass er als das aufgefasst wird, als was er gemeint ist: konstruktive Kritik.

Eine letzte Sache noch. Sollte es zu einem Nachfolger zu diesem Buch kommen, hätte ich noch eine Anregung. Wie wäre es, wenn man ein wenig auf Design Patterns eingeht? Notifications sind ja zum Beispiel eine Implementation des Observer Patterns, was ich für durchaus erwähnenswert halte.

Liebe Grüße
Christian
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Meinen Einstieg in die Cocoa Entwicklung fand ich vor ungefähr drei Jahren mit "Cocoa Programming for Mac OS X" von Aaron Hillegass. Weiters haben mich bei meinen ersten Schritten Steven Kochans "Programming in Objective-C" und "Core Mac OS X and Unix Programming" von Aaron Hillegass und Mark Dalrymple begleitet. Obwohl diese Bücher mittlerweile schon recht alt sind, kann ich diese Kombination jedem empfehlen, der am Mac programmieren lernen will.
Eines der von dir zitierten Bücher enthält recht viele Memory Leaks. Das bemerkt der Leser nicht. Vielmehr bekommt er ein gefährliches System beigebracht, in dessen Fallen der Autor selbst zahlreich tappt. Da dies der Leser nicht bemerkt, lernt er dies auch noch. Ich kann das nicht empfehlen.

Überhaupt sind in den zitierten Büchern die Ausführungen zur Speicherverwaltung, eines der Grundthemen und häufigsten Fehlerquelle nur rudimentär behandelt. So darf man auf keinen Fall Leute los lasssen, wie zahlreiche Applikationen (auch von Apple) zeigen.

Ich habe mir also "Objective-C und Cocoa" gekauft. Die ersten fünf Kapitel habe ich nur überflogen, da es für mich hier nicht sonderlich viel zu lernen gab. Ab Kapitel 6 hab ich die Beispiele mitgemacht.
Man merkt, dass du von etwas sprichst, was du nicht gelesen hast. Dazu sogleich:

Das GridView Beispiel fand ich recht nett, wenn vielleicht auch für manchen Einsteiger zu umfangreich. Hier wären zumindest die schon angesprochenen Hervorhebungen für Code-Änderungen recht wichtig. Die Fehler in diesem Kapitel könnte man vielleicht noch als "Feature" abtun. Wenn man konzentriert bei der Sache ist, findet man sie auch ohne Probleme. Trotzdem - schön ist das nicht und die Tatsache, dass im Beispiel acceptsFirstResponder: fehlt, ist für einen Anfänger schon schwer zu finden. Errata hin oder her.
Das halte ich in der Tat für den schwersten Fehler. Er gehört in die Kategorie der eingangs erwähnten Memory Leaks, da man zunächst nicht weiß, woran es liegt. Aber immerhin wird man darauf hingewiesen, weil das Programm nicht funktioniert. Bei den Memory Leaks sieht alles ordnungsgemäß aus.

Außerdem ist es auch sehr unschön, dass die meisten Methoden nicht im Header deklariert sind. Da das Beispiel ohnehin schon sehr groß ist, hätte man vielleicht an dieser Stelle auch zeigen können, wie man über Categories private Methoden in Objective-C implementiert. Dann würde auch beim Übersetzen nicht so lange nach Abhängigkeiten gesucht werden und man hätte die Methoden trotzdem nicht im Header bekannt machen müssen.
Diese Ausführungen sind grob fehlerhaft, sorry:

a) Man macht einfach Methoden nicht öffentlich, indem man sie *nicht* in den Header schreibt. Dein Vorschlag, alle da herein zu schreiben und dann wieder mit Kategorien heraus zu nehmen, ist von hinten durch die Brust ins Auge: Erst ein Problem schaffen, welches ich dann beseitige.

b) Das hat dann keine Auswirkungen auf die Übersetzungszeit.

c) Du hättest vielleicht einfach mal vor Kapitel 6 lesen sollen. Da steht das nämlich. Das hätte auch den Vorteil, dass du wüsstest, wovon du schreibst.

Was mir aber besonders bitter aufgestoßen ist, ist die Verwendung von einleitenden Underscores bei Attributnamen. Diese sind aus gutem Grund Apple vorbehalten! Was wäre zum Beispiel, wenn Apple in einer der Superklassen plötzlich ein gleichnamiges Attribut einführt?
Der Voorwurf ist fehlerhaft:

a) Auf die Konvention wird eingegangen. Du hättest vielleicht vor Kapitel 6 lesen sollen. Dann wüsstest du, wovon du sprichst.

b) Was passiert denn? Wenn du mit Underscores arbeitest, gibt es einen Übersetzungsfehler, den du beseitigen musst. Wenn du ohne Underscore arbeitest, dann gibt es *keinen* Übersetzungsfehler, das Programm funktioniert jedoch äußerst wundersam.
na, was hältst du für besser? Fröhliche Ferhlersuche!

Weiters führt das zu Problemen beim Key-Value Coding und bei Bindings. Das ist sehr schlechter Programmierstil! Unter "Key-Value Coding Fundamentals" kann man bei Apple folgendes lesen:
Das ist mit Verlaub völliger Schmarren:

a) KVC und KVO (das meinst du wohl, mit Bindings selbst hat das ziemlich genau gar nichts zu tun) suchen zuerst nach Accessoren. Da in sämtlichen Fällen entsprechende Accessoren vorhanden sind, kann für KVC und KVO die Instanzvariable heißen wie sie will. Es kann sich auch um eine berechnete Variable handeln. Dies wird auch im Kapitel 9 ausgeführt. Du hättest es halt lesen müssen, damit du weißt, wovon du sprichst.

b) Wenn KVC (KVO funktioniert dann schon gar nicht mehr, auch dies wird ausgeführt) keine Accessoren findet, dann sucht es nach Instanzvariablen. *Dies* ist schlechter Programmmierstil. Es sei nur nebenbei bemerkt, dass es sowohl nach Instanzvariablen mit und ohne Underscore sucht. Es sei noch angemerkt, dass in dem Falle der nachträglichen Erweiterung wiederum das Programm wudnerlichste Zustände zeitigen wird, ohne dass der Compiler warnt. Ich finde das noch immer deutlich schlechter. Ich habe mich zwar dazu entschlossen, künftig den Underscore wegzulassen, weil es einfach "kompatibler" mit anderen Quellen ist. Besser ist es ganz gewiss nicht.

"Keys must use ASCII encoding, begin with a lowercase letter, and may not contain whitespace."
Dieser Hinweis zeugt von grober Unkennntnis. In keinem einzigen Fall werden Keys verwendet, die mit einem Underscore beginnen. Es werden Instanzvariablen mit Underscore verwendet. Dies ist *nicht* das gleiche.

Du hast hier dringenden Nachholbedarf, was KVC und KVO angeht.(Mit Bindings hat das immer noch nichts zu tun, was auf weiteren Nachholbedarf schließen lässt.)

Die Dichte deiner Fehler in diesem Beitrag werden sicherlich vom Buch nicht erreicht. Es zeigt aber auch, und das ist wesentlicher, dass die von dir zitierte Lektüre das offenbar nicht, fehlerhaft oder nur rudimentär vermittelt hat. Du hast damit ein wunderbares Gegenargument geliefert. Danke!

Auch versöhnlich (Pack schlägt sich, Pack vertägt sich.)
Zu keinem Zeitpunkt war das Buch als theoretisches Standardwerk geplant. Es wird künftig mehr zu Design-Patterns geben, aber ganz gewiss nicht so, wie du dir das vorstellst. Mehr "By the way". Das mag man gut finden, hiflreich, nicht-hilfreich, schlecht, was weiß ich. Wenn du ein solches Werk möchtest, musst du dir einfach ein anderes Buch kaufen.

Ich empfehle dir allerdings ganz ohne Arroganz ganz dringend die Lektüre des Buches.

BTW: Ich habe zu einigen Stellen keine Stellung bezogen, weil sie mich sozusagen "nichts angehen". Teilweise teile ich deine Kritik, teilweise nicht.

Noch BTW: Bemerkenswert finde ich noch, dass du mich offenbar kennst, du dir aber extra für diesen Beitrag einen neuen Account zugelegt hast. Im Entwicklerforum gibt es auch gerade zwei Beiträge in einem Thread von dir, der zudem nicht zum Cocoa-Forum gehört.
 
Zuletzt bearbeitet:

pepi

Cellini
Registriert
03.09.05
Beiträge
8.740
Vorweg eine Entschuldigung an den Thread-Ersteller. Sorry fürs Threadjacking!

Eines der von dir zitierten Bücher enthält recht viele Memory Leaks. Das bemerkt der Leser nicht. Vielmehr bekommt er ein gefährliches System beigebracht, in dessen Fallen der Autor selbst zahlreich tappt. Da dies der Leser nicht bemerkt, lernt er dies auch noch. Ich kann das nicht empfehlen.
Auf die Gefahr hin, daß ich mich wiederhole...
Daß "die Konkurrenz" es anders oder (noch) schlechter macht ist kein Grund dafür sich selbst nicht weiter zu verbessern.[...]
...aber in dieser Hinsicht waren wir einander ja schon einig.

[...]
Ich habe mir also "Objective-C und Cocoa" gekauft. Die ersten fünf Kapitel habe ich nur überflogen, da es für mich hier nicht sonderlich viel zu lernen gab. Ab Kapitel 6 hab ich die Beispiele mitgemacht.
[...]
Was mir aber besonders bitter aufgestoßen ist, ist die Verwendung von einleitenden Underscores bei Attributnamen. Diese sind aus gutem Grund Apple vorbehalten! Was wäre zum Beispiel, wenn Apple in einer der Superklassen plötzlich ein gleichnamiges Attribut einführt? Weiters führt das zu Problemen beim Key-Value Coding und bei Bindings. Das ist sehr schlechter Programmierstil! Unter "Key-Value Coding Fundamentals" kann man bei Apple folgendes lesen:

"Keys must use ASCII encoding, begin with a lowercase letter, and may not contain whitespace."

[...]
Trotzdem kann man meiner Ansicht nach die Autoren nicht ganz aus der Pflicht entlassen. Das Buch hätte riesiges Potential, was leider verschenkt wurde. Etwas mehr Sorgfalt hätte dem Werk sehr gut getan.
[...]
Die einleitenden Underscores empfinde ich persönlich als extrem unübersichtlich, ungeachtet dessen ob Apple nun empfiehlt oder erlaubt solche zu verwenden. Sie sind sehr dafür geeignet die _attribute und attribute zu verwechseln was in Kapitel 3 im abgedruckten Code auch schon genau so passiert. (Auf diesen Bug habe ich schon in eine früheren Posting hingewiesen.)
Christians Erläuterung bestätigt hier mein Gefühl, daß das fürchterlich unpraktisch ist. Ich bin sicher, daß das Fehler im Code provoziert die man stundenlang suchen kann. Nicht unbedingt das was ich als "Best Practice" empfinde.
In Passagen wirkt das Buch tatsächlich entweder unter starkem Zeitdruck geschrieben oder einfach nur per Copy Paste umgebastelt. Teilweise Fehler die auch ein Themenfremder Lektor definitiv erkennen hätte können, vorausgesetzt daß wirklich ein solcher sich des Buches angenommen hat. (Kapitel 3...Klavier...Gitarre...)

Amin bezugnehmend auf das vorgehende Posting von zirpl (Christian):
[...]Man merkt, dass du von etwas sprichst, was du nicht gelesen hast.[...]
Die Dichte deiner Fehler in diesem Beitrag werden sicherlich vom Buch nicht erreicht. Es zeigt aber auch, und das ist wesentlicher, dass die von dir zitierte Lektüre das offenbar nicht, fehlerhaft oder nur rudimentär vermittelt hat. Du hast damit ein wunderbares Gegenargument geliefert. Danke!

Andererseits glaube ich nicht, dass deine zahlreichen Fehler in diesem Beitrag an deiner Literaturempfehlung liegt. Ich denke, sie liegen eher bei dir.
Auch wenn ich hier eindeutig der Anfänger in Sachen Objective-C und Cocoa bin, so bin ich doch davon überzeugt, daß man einem Herrn Aaron Hillegass alles vorwerfen kann, aber sicherlich nicht Unkenntnis oder fehlerhafte Vermittlung von Objective-C und Cocoa Inhalten. Soweit traue ich mir selbst das zu beurteilen zu. Es hat mehr als einen Grund warum "Cocoa® Programming for Mac® OS X" und "Programming in Objective-C" als die Standardwerke gelten.

Ich bin auch sicher, daß persönliche Angriffe und der Vorwurf der Unkenntnis (nicht nur) hier definitiv nichts verloren haben. Ich glaube nicht, daß jemand der Dein Buch wie Du sagst nicht gelesen hat derart detailliert darüber schreiben würde.

Ich muß dazu noch erwähnen, daß ich selbst momentan erst mit Kapitel 4 kämpfe und mich bisher schon mehrfach über nervige Tippfehler geärgert habe. Das ist einfach nicht das was ich von so einem Buch erwarte. (Wodurch die grundsätzlich entstanden sind ist für mich als zahlende Zielgruppe eigentlich herzlich unerheblich.)

Ich kann die durchklingende Enttäuschung von zirpl verstehen und nachvollziehen. Gute Bücher sind meist nicht billig und mein Bücherregal kann man durchaus bereits als Wertanlage bezeichnen. Trotzallem sind 50€ nicht wenig Geld die man in Literatur natürlich gut angelegt haben möchte. Wenn das Buch dann Qualitativ in manchen Teilen wirklich unangenehm auffällt bleibt der Frust nicht aus.

Ich würde mich freuen wenn auch meine Kritik nicht persönlich negativ aufgefasst würde sondern als Ansporn die Dritte Auflage des Buches besser zu gestalten. Immerhin ist es uns doch allen ein Anliegen, daß es viele gute Programmierer für den Mac gibt die viele viele tolle Applikationen schreiben, oder?
Gruß Pepi
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Er hat einen Vergleich angestellt, nicht ich. Nicht wahr? Dann werde ich auch zu dem Vergleich etwas sagen können. Oder?

Der fehlende Underscore, erzeugt Fehler. Besonders beliebt ist es, eine Shadow zu erzeugen, oder aber, die Parametervariable wird anders benannt und man hat schwudiwupp versehentlich die Instanzvariable anstelle der Parametervariable verwendet. *Das* passiert mir sehr häufig, seitdem ich mich umgestellt habe.

Der "Rat" von Apple ist nicht nachvollziehbar. Das von ihm angesprochene Problem der Erweiterung der Grundklasse löst es nicht, sondern verschlimmert es ganz im Gegenteil. Überlege dir selbst, was dann passiert, wenn man Apples Rat folgt: Kein Compilerfehler, aber ein völlig zufällig verhaltendes Programm, dessen verhalten vom fremden und nicht-offenen Code abhängt. *Das* kann man jahrelang suchen.

Bei Verwendung von Underscores in Accessoren kann es genau eine Stelle im Code geben, an dem der Fehler auftritt: In den Accessoren. Das sind wenige Zeilen. Ich verstehe nicht, wie man da stundenlang suchen kann.

Zudem hat er selbst gesagt, dass er es nur überflogen hat. Ich habe auch konkret darauf hingewiesen, was er offenkundig nicht gelesen hat. Wenn ganze Subkapitel als fehlend bezeichnet werden, er hier über KVC und Bindings schreibt, obwohl er nach eigenen Angaben nicht einmal bis dahin gekommen ist, hat er es nicht gelesen. Soll ich die konkreten Stellen im Buch heraussuchen?

Er hat zudem das Verhältnis von KVC, KVO, Bindings und Instanzvariablen nicht einmal ansatzweise verstanden. Das ist so, wenn er behauptet, die Bezeichnung von Instanzvariablen könne da zu Problemen führen. Das ist mit Verlaub völliger Schmarren. Du kannst die entsprechende Instanzvariable Tir__iÖÖlö nennen und wirst kein Problem mit KVC, KVO und Bindings haben. Dann verwechselt er noch Instanzvariablen mit Keys, obwohl es dazwischen keinen Zusammenhang bei KVO und Bindings gibt, bei KVC nur dann, wenn man fehlerhaft programmiert.

Sorry, er hat davon keine Ahnung. Ich kann nicht beurteilen, warum dies nach der Lektüre der von ihm angegebenen Literatur so ist. Ich sehe aber, dass es so ist.

Übrigens halte ich viel von inhaltlichen Argumenten, warum etwas so ist. Für kein inhaltliches Argument halte ich es, dies an Personen zu binden. Das Standardwerk der Memory Leaks stammt allerdings von Herrn Hillegass. Die nächste Auflage erscheint dann ja wohl auch nach der Einführung der GC. Besser ist das.

BTW: Wenn habe ich denn zuerst persönlich angegriffen? verteidigen darf ich mich doch mit gleicher Waffe, oder?

+++

Einne Kritik, die von Unkenntnis der kritisierten Thematik beherrscht ist, ist nicht sinnvoll. Im übrigen darf ich dich darauf hinweisen, dass ich berechtigter Kritik zugestimmt habe. Ich werde aber nicht unhaltbarer Kritik zustimmen. Sorry.

+++

Man kann das keinesfalls auf das Lektorat schieben. Im Code wird es immer Fehler geben. Und das soll keine Entschuldigung sein, aber: Das ist in allen Büchern so. Manche sagen das bloß, andere sagen das nicht. Ich halte es für meine Verantwortung, es zu sagen.
 
Zuletzt bearbeitet:

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Mal zum Beleg, weil ja doch Sachargumente zählen:

Behauptung:
Mit Underscores in eigenen Bezeichnern vermindert sich das Problem von nachträglichen Erweiterungen der Basisklasse. (Eines der fragile-Baseclass-Probleme)

Ausgangslage:
Gedachte Basisklasse aus Cocoa
Code:
@interface NSCocoaClass : NSObject {
    NSString* _attribute; // privates Attribut von Apple
}

- (NSString*)attribute; // öffentlicher Getter
- (void)setAttribute:(NSString*)value; // öffentlicher Setter
@end

Eigene Ableitung
Code:
@interface MyClass : NSCocoaClass {
    NSString* title; // Eigenes Attribut ohne Underscore
}

- (NSString*)title;
- (void)setTitle:(NSString*)value;
@end

Jahre ziehen ins Land, Apple erweitert die Basisklasse just um mein Attribut Title. Die Basisklasse sieht jetzt so aus:
Gedachte Basisklasse aus Cocoa
Code:
@interface NSCocoaClass : NSObject {
    NSString* _attribute; // privates Attribut von Apple
    NSString* _title; // Neue Instanzvariable
}

- (NSString*)attribute; // öffentlicher Getter
- (void)setAttribute:(NSString*)value; // öffentlicher Setter

- (NSString*)title; // öffentlicher Getter
- (void)setTitle:(NSString*)value; // öffentlicher Setter
@end

Sieht doch okay aus, nicht wahr. "title" stört "_title" nicht. Pustekuchen! Denn die Accessoren heißen jetzt gleich. Daraus folgt:

1. Statt zweier unterschiedlicher Instanzvariablen _title und title wird jetzt stets nur noch title benutzt. Denn meine Accessoren für meine Instanzvariable überschreiben die Accessoren für die Instanzvariable in NSCocoaClass. Daran hat der Compiler genau nichts auszusetzen und übersetzt das einwandfrei. Das Laufzeitsystem hat genau nichts auszusetzen und führt das einwandfrei aus.

2. Mein Code geht davon aus, meine Instanzvariable zu setzen. Apples Code geht davon aus, Apples Instanzvariable zu setzen. Die gleiche Instanzvariable wird daher vollkommen wild von unterschiedlichen Code gesetzt. Macht der Code von Apple oder mein Code irgendetwas asynchron, so bekommt der andere Code völlig unerwartet neue Werte. Locks funktionieren nicht mehr. Denn Apple hat einen Lock für seine Instanzvariable, ich habe einen Lock für meine Instanzvariable. Das ist aber übber den gleich lautenden Setter dieselbe Instanzvariable.

3. Wie soll ich das testen? Ich sehe nur, dass da irgendwas unter möglicherweise mir völlig transparenten Umständen (Ich kenne den Code von Apple nicht, und weiß daher nicht, wann deren Implementierung den Setter benutzt!) verändert wird. Ich stehe erst einmal mit einem dicken Fragezeichen im Gesicht vor meinem Laufzeitverhalten.

4. Möglicherweise bekomme ich dann durch Zurückverfolgung darauf, dass die Instanzvariable irgendwann neu gesetzt wird. Dann setze ich einen Breakpoint darauf und erkenne noch, dass irgendwo der Setter aufgerufen wird. Nichts genaues weiß ich nicht, weil ich den Code von Apple nicht halte.

Halte ich mich indessen nicht an die Unterzugregel und verwende einen, schmeißt mir das sofort der Compiler von hier bis Bagdad um die Ohren und ich habe mutmaßlich drei Jahre meines Lebens besser verbracht.

Sorry, mir ist ziemlich gleichgültig, ob das Apple, Gott, Hillegass, Schmitz oder Müller propagieren. Das ist nicht vorteilhaft und löst genau gar kein Problem.
 
Zuletzt bearbeitet:

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Mal zum Beleg, weil ja doch Sachargumente zählen:

Behauptung:
Die Änderung der Bezeichnung (mit oder ohne Unterzug oder ganz anders) der Instanzvariable beeinflusst das Verhalten von KVC bei existierenden Accessoren nicht.

Beispielklasse.h
Code:
@interface MyClass : NSObject {
    NSString* attribute;
}

- (NSString*)attribute;
- (void)setAttribute:(NSString*)value;
Beispielklasse.m
Code:
@implementation MyClass
- (NSString*)attribute { return attribute; }
- (void)setAttribute:(NSString*)value {
    if( value != attribute ) {
        [attribute release];
        attribute = [value copy];
    }
}

Ich greife per KVC auf die Eigenschaft zu:
Irgendwo.m
Code:
…
NSString* attribute = [object valueForKey:@"attribute];
…

Nach dem hier:
valueForKey:
Returns the value for the property identified by a given key.

- (id)valueForKey:(NSString *)key

Parameters
key
The name of one of the receiver's properties.

Return Value
The value for the property identified by key.

Discussion
The default implementation works as follows:

1. Searches for a public accessor method based on key. For example, with a key of “lastName”, valueForKey: looks for a method named getLastName or lastName.
2. If a public accessor method is not found and the class method accessInstanceVariablesDirectly returns YES, searches for a private accessor method based on key (a method preceded by an underbar). For example, with a key of “lastName”, valueForKey: looks for a method named _getLastName or _lastName.
3. If an accessor method is not found valueForKey: searches for an instance variable based on key and returns its value directly. For the key “lastName”, this would be _lastName or lastName.
4. If neither an accessor method nor an instance variable is found, the default implementation invokes valueForUndefinedKey:.
Dies bedeutet, dass mein Accessor aufgerufen wird. Wie die Instanzvariable heißt, ist irrelevant.

Ändern wir das also mit Unterzug-Benennung:
Beispielklasse.h
Code:
@interface MyClass : NSObject {
    NSString* _attribute;
}

- (NSString*)attribute;
- (void)setAttribute:(NSString*)value;
Beispielklasse.m
Code:
@implementation MyClass
- (NSString*)attribute { return _attribute; }
- (void)setAttribute:(NSString*)value {
    if( value != _attribute ) {
        [_attribute release];
        _attribute = [value copy];
    }
}

So gilt immer noch das hier:
valueForKey:
Returns the value for the property identified by a given key.

- (id)valueForKey:(NSString *)key

Parameters
key
The name of one of the receiver's properties.

Return Value
The value for the property identified by key.

Discussion
The default implementation works as follows:

1. Searches for a public accessor method based on key. For example, with a key of “lastName”, valueForKey: looks for a method named getLastName or lastName.
2. If a public accessor method is not found and the class method accessInstanceVariablesDirectly returns YES, searches for a private accessor method based on key (a method preceded by an underbar). For example, with a key of “lastName”, valueForKey: looks for a method named _getLastName or _lastName.
3. If an accessor method is not found valueForKey: searches for an instance variable based on key and returns its value directly. For the key “lastName”, this would be _lastName or lastName.
4. If neither an accessor method nor an instance variable is found, the default implementation invokes valueForUndefinedKey:.

Es wird also immer noch mein Getter aufgerufen und das funktioniert immer noch. Da gibt es gar kein Problem.

Sogar wenn ich keinen Accessor habe, funktioniert das wegen 3. immer noch! Aber da ich einen Accessor habe (Steht im Buch, in den Teilen, die überflogen wurden.), kannn ich die Instanzvariable sogar dumdidum nennen.

Beispielklasse.h
Code:
@interface MyClass : NSObject {
    NSString* _dumdi_du_m;
}

- (NSString*)attribute;
- (void)setAttribute:(NSString*)value;
Beispielklasse.m
Code:
@implementation MyClass
- (NSString*)attribute { return _dumdi_du_m; }
- (void)setAttribute:(NSString*)value {
    if( value != _dumdi_du_m ) {
        [_dumdi_du_m release];
        _dumdi_du_m = [value copy];
    }
}

Das funktioniert immer noch prima.

Sorry, wer als jahrelanger Programmierer wie zirpl das nicht weiß, obwohl er drei Standardwerke gelesen hat, macht entweder etwas falsch oder die Standardwerke. Jedenfallls ist es so, wie ich es schreibe, richtig.
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Mal zum Beleg, weil ja doch Sachargumente zählen:

Behauptung:
Die Änderung der Bezeichnung (mit oder ohne Unterzug oder ganz anders) der Instanzvariable beeinflusst das Verhalten von KVO nicht.

Nach der sehr kurzen Erläuterung von Apple:
Automatic key-value observing is implemented using a technique called isa-swizzling.

The isa pointer, as the name suggests, points to the object's class which maintains a dispatch table. This dispatch table essentially contains pointers to the methods the class implements, among other data.

When an observer is registered for an attribute of an object the isa pointer of the observed object is modified, pointing to an intermediate class rather than at the true class. As a result the value of the isa pointer does not necessarily reflect the actual class of the instance.

Instead of relying on the isa pointer your application should use the class method to determine the class of an object instance.
Wird die Überwachung eingerichtet, indem eine Zwischeninstanz mittels isa-Swizzling eingebaut wird, die die Methodenliste verändert. Das bedeutet, dass sich KVO genau einen feuchten Kehrricht darum kümmmert, wie meine Instanzvariable heißt. Wer es wegen der knappen Doku nicht glaubt, mag mal selbst unmitelbar einen Wert an eine Instanzvariable (ohne Setter) zuweisen und bis Silvester 2079 auf die Observierungsnachricht warten. Die gibt es nicht, weil KVO alleine an den Methoden hängt.

Weil die Doku von Apple so knapp ist, stelle ich das übrigens klar. Auf Seite 507 schreibe ich hierzu:
Bleibt die Frage, wie das funktioniert. […] Durch die Anmeldung der Observierung merkt sich Cocoa für das Objekt, dass uns ein Aufruf der Methode -setRemark: mitgeteilt werden muss. […] Findet es eine Nachricht setRemark, so wird automatisch Observierung aktiviert.
Da habe ich nichts von Instanzvariablen geschrieben. Das hat einen Grund: Sie haben damit nichts zu tun.

Sorry, wer als jahrelanger Programmierer wie zirpl das nicht weiß, obwohl er drei Standardwerke gelesen hat, macht entweder etwas falsch oder die Standardwerke. Jedenfallls ist es so, wie ich es schreibe, richtig.
 
Zuletzt bearbeitet:

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Mal zum Beleg, weil ja doch Sachargumente zählen:

Behauptung:
Bindings haben mit Instanzvariablen überhaupt nichts am Hut.

Nach der Doku hier, wird einfach zur Observierung KVO verwendet:
When a new binding is created it relates the receiver’s binding (for example, a property of the view object) to a property of the observable object specified by a key path. When the value of the specified property of the observable object changes, the receiver is notified using the key-value observing mechanism.

Das bestätigt der Sample-Code:
Code:
static void *AngleBindingContext = (void *)@"JoystickAngle";
 
- (void)bind:(NSString *)binding
 toObject:(id)observableObject
 withKeyPath:(NSString *)keyPath
 options:(NSDictionary *)options
{
 // Observe the observableObject for changes -- note, pass binding identifier
 // as the context, so you get that back in observeValueForKeyPath:...
 // This way you can easily determine what needs to be updated.
 
if ([binding isEqualToString:@"angle"])
 {
    [observableObject addObserver:self
                   forKeyPath:keyPath
                  options:0
                  context:AngleBindingContext];
 
    // Register what object and what keypath are
    // associated with this binding
    observedObjectForAngle = [observableObject retain];
    observedKeyPathForAngle = [keyPath copy];
 
    // Record the value transformer, if there is one
    angleValueTransformer = nil;
    NSString *vtName = [options objectForKey:@"NSValueTransformerName"];
    if (vtName != nil)
    {
        angleValueTransformer = [NSValueTransformer
            valueTransformerForName:vtName];
    }
 }
 // Implementation continues...

Wie man leicht erkennen kann, wird einfach auf ein Schlüsselwort für die Eigenschaft des gebundenen Objektes KVO eingerichtet. Den Pfad,den ich übergebe, ist einfach ein Pfad für die Observierung. Dies bedeutet, dass Bindings gar nicht in Verbindung auch nur mit meiner Instanz treten. Sie überlassen das KVO.

Wie oben ausgeführt, fasst KVO aber wiederum nicht meine Instanzvariablen an, sondern verlässt sich auf meine Accessoren. Wie ebenfalls ausgeführt, ist es aber meine Sache, wie meine Accessoren auf meine von mir benannten Instanzvariablen zugreifen. Der Weg ist in etwa so:

Binding -- richtet ein -> KVO -- benutzt -> MeineAccessoren -- greift zu auf -> Meine Instanzvariablen.

Das ist dermaßen mehrfach gekapselt, dass alleine der Gedanke, der Name meiner Instanzvariablen könne etwas mit Bindings zu tun haben, völlig absurd ist.

Bindings sind nichts anderes als eine Art KVO-Setter, mit dem ich sagen kann, dass ein anderes Objekt eine Observation einrichten soll.

Weil übrigens wegen der mangelhaften Besprechung in so genannten Standardwerken hier weit Verwirrung und Unkenntnis herrscht, schreibe ich das auch, nämlich auf Seite 508:
[…]Der Controller [= Custom-Controller im Nib] ist jedoch derjenige, der die Observierung einrichtet und die Überwachungsfunktion -observeValue:[…] implementiert. Damit muss der Controller spezialisiert bleiben auf die Views, die er verwaltet. Dabei könnte man die Sache doch intelligenter angehen. Jedes View könnte sich ja selbst eine Observation einrichten. Dann müsste man nur noch sagen, wo genau im Model diese Observation angelegt werden soll. Genau dies ist die Idee von Bindings.
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
So, dies mal nur als Beispiele von Kritik. Ich verstehe es absolut, wenn sich jemand sich aufregt, weil er bemerkt, dass die Datei Klasse.m statt ObjectiveC.m heißt und er sucht. Mea culpa und nervig.

Ich halte es indessen immer noch für deutlich schlechter, wenn jemand nach der Lektüre von drei Standardwerken Grundtechnologien von Cocoa nicht verstanden hat und dies nicht bemerkt.

Und das liegt nicht an zirpl. Diese Vorurteile findet man zuhauf in Foren.
 

pepi

Cellini
Registriert
03.09.05
Beiträge
8.740
[...]Bei Verwendung von Underscores in Accessoren kann es genau eine Stelle im Code geben, an dem der Fehler auftritt: In den Accessoren. Das sind wenige Zeilen. Ich verstehe nicht, wie man da stundenlang suchen kann.
[...]
Man kann das keinesfalls auf das Lektorat schieben. Im Code wird es immer Fehler geben. Und das soll keine Entschuldigung sein, aber: Das ist in allen Büchern so. Manche sagen das bloß, andere sagen das nicht. Ich halte es für meine Verantwortung, es zu sagen.
[...]
Sorry, mir ist ziemlich gleichgültig, ob das Apple, Gott, Hillegass, Schmitz oder Müller propagieren. Das ist nicht vorteilhaft und löst genau gar kein Problem.
Ich glaube wir sind d'accord, daß sich Dein Buch an Einsteiger in Objective-C und Cocoa richtet. Zu denen zähle ich mich, was auch der Grund dafür war, daß ich Dein Buch käuflich erworben habe. Nämlich um mir entsprechende Fähigkeiten über diese Thematik anzueignen. Auch ich verfüge über langjährige Programmiererfahrung, allerdings in anderen Bereichen/Sprachen.

Als Anfänger muß man auf das Buch vertrauen. Man selbst hat noch nicht die Kenntnisse und das Gespür für den Code. Folglich ist eine korrekte Syntax und auch ein gleichbleibender Stil im Code vonnöten.

Aus Objective-C und Cocoa, Kapitel 3 C und Objective-C, Seite 119 oben:
Code:
-(void)setKeyCount:(NSNumber*)keyCount
{
    if( _keyCount != keyCount ) {
        [keyCount release];
        _keyCount = [keyCount retain];
    }
}
Ich bin sicher, daß ein Anfänger diesen Code aufgrund dreier unterschiedlicher Dinge die alle mit keyCount oder _keyCount bezeichnet werden nicht unbedingt sehr übersichtlich finden wird. Es fällt nicht unbedingt leicht die Instanzvariable _keyCount, den Methodennamen keyCount und die lokale Methodenvariable keyCount auseinander zu halten. Die enorme Verwechslungsgefahr und Unübersichtlichkeit ist mein konkreter Kritikpunkt gewesen.
(Ich bitte als lernwilliger Anfänger um Nachsicht und bitte mich zu korrigieren falls ich hier etwas falsch verstanden habe. )

Für Dich mag das peinlich primitiv sein wenn ich da ein wenig brauche um den Fehler zu finden, es sollte Dir aber meiner Ansicht nach nicht gleichgültig sein. Hinzu kommt die uneinheitliche Syntax im Code. Ja, über die korrekte Setzung von { und } sind schon mehrere Flamewars gestartet worden, aber es wäre schon hilfreich wenn im Buch wenigstens einheitlich immer die selbe Art der Syntax verwendet würde, unabhängig davon welche der Autor oder der Proband nun bevorzugt.

Immerhin ist obiger Bug in den Errata zum Buch angeführt. Trotzallem halte ich folgende Version für weniger Fehlerträchtig und übersichtlicher:
Code:
-(void)setKeyCount:(NSNumber*)keyCount {
    if( myKeyCount != newKeyCount ) {
        [newKeyCount release];
        myKeyCount = [newKeyCount retain];
    }
}
Hier wird der Bug doch deutlicher klar da die Bezeichner aussagekräftiger gewählt sind. Auch wenn es nur ein paar Zeilen sind, wäre mein Problem dadurch ganz leicht gelöst.

Ich kämpfe mich nun noch durch das Unterkapitel "Gruppendynamik in der Praxis" und wünsche präventiv eine geruhsame Nacht.
Gruß Pepi
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Die Gleichnamigkeit von Methode und Attribut ist als Naming-Rule vorgeschrieben, sinnvooll und in zahlreichen Programmiersprachen mit Nuancen verwendet. Das macht man in etwa auch in C++ oder Java so.

Du kannst das kritisieren, oder auch nicht. Es ist ganz üblich so.

Den Dritten im Bunde, nämlich den Parameter der Methode, könntest du nennen, wie du lustig bist. Die Standards nehmen da value, also nichts mit my oder new. Das Problem wird also gerade nicht bei dem Unterzug gelöst, sondern bei Parameter! Und das ist ja auch logisch: Sonst hätte ja Apple das Problem. Die wollen den Unterzug ja benutzen. Bemerke das: Was du alos fehlerhaft, nachteilig, verwechslungsanfällig beziechnest, ist die interne Coding-Richtlinie von Apple! Sooooooo schlimm kann das denn ja nun dann doch nicht sein, oder?

Inzwischen mag ich es am meisten, in der Deklaration der Methode einen aussagekräftigen Text wie keyCount im Beispiel zu nehmen und in der Implementierung dann auf value zu wechseln. Ja, das ist erlaubt. Es würde aber mutmaßlich wiederum zu Kommentaren führen, dies sei verwirrend. :) (Es hat sogar an einer Stelle dazu geführt.)

Die Alternative, den Unterzug bei den Instanzvariablen wegzulassen, ändert daran gar nichts. Du bekommst dann nämlich Verwechselungen vor allem bei den Initialisierern. Ich habe dazu auch schon etwas geschrieben (weniger ausführlich als hier):
http://www.cocoading.de/Tutorials/Das_Kind_beim_Namen_nennen.html

Dann gibt es noch die Möglichkeit, ein init voranzustellen. Das funktioniert häufig bei funktionalen Methoden nicht.

Wie gesagt: Auf Gründen der "Kompatibilität" nehme ich selbst keine Unterzugvariablen mehr. Das hat bei mir zu einer deutlichen Steigerung der Fehlerrate geführt -- und zu Nervereien bei der Auswahl der Bezeichner. Erst gerade heute habe iich mich wieder darüber geärgert. Praktischer ist das gewiss nicht, ich habe schon beides gemacht. Darüber hinaus irgendwie funktional störend ist der Unterzug ganz, ganz gewiss nicht, siehe oben. Und da bleibe ich dabei: Wenn die Leute zuhauf die Schlüsseltechnologien von Cocoa nicht richtig verstanden haben, dann ist das ein Problem der Literaturlage. Kein Problem, welches unmittelbar auffällt, welches aber offenkundig besteht. Ich behaupte ernsthaft, dass keines der genannten Werke Speicherverwaltung und die "KV-Technologien" nur ansatzweise so lehrreich bespricht.
 
Zuletzt bearbeitet:

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
BTW: Ich bin ja nicht ganz blöde. Natürlich habe ich mir vorher im Entwicklerforum angeschaut, wo die Leute Probleme haben. Das waren jetzt nicht irgendwelche Einsteiger, denen es vllt noch an Erfahrung und Gewöhnung fehlt, sondern Leute, die ich für gut halte.

Und natürlich habe ich mir diese Problemfelder notiert und darauf geachtet, dass das ausführlicher und genauer geschrieben wird.
 

zirpl

Golden Delicious
Registriert
28.09.07
Beiträge
10
Eines der von dir zitierten Bücher enthält recht viele Memory Leaks. Das bemerkt der Leser nicht. Vielmehr bekommt er ein gefährliches System beigebracht, in dessen Fallen der Autor selbst zahlreich tappt. Da dies der Leser nicht bemerkt, lernt er dies auch noch. Ich kann das nicht empfehlen.

Überhaupt sind in den zitierten Büchern die Ausführungen zur Speicherverwaltung, eines der Grundthemen und häufigsten Fehlerquelle nur rudimentär behandelt. So darf man auf keinen Fall Leute los lasssen, wie zahlreiche Applikationen (auch von Apple) zeigen.

Das Standardwerk der Memory Leaks stammt allerdings von Herrn Hillegass.

Meine Hauptliteratur war tatsächlich "Cocoa Programming for Mac OS X" - Kochans Buch diente nur als Begleitbuch. Besonders ersteres genießt in der Mac-Entwicklerwelt jedoch einen ausgezeichneten Ruf. Durchaus möglich, dass sich auch darin Fehler befinden, aber ich hatte nie Probleme mit Leaks.

Eine alte Weisheit besagt, dass man sich selbst nicht besser macht, indem man andere schlechter macht. Ich halte das im Gegenteil für eine sehr schwache Argumentation. Aaron Hillegass bringt als Entwickler der sowohl bei NeXT als auch bei Apple gearbeitet hat eine äußerst gute Reputation mit. Natürlich macht auch er Fehler. Es zeugt jedoch von sehr großem Selbstbewusstsein, ihn als Stümper hinzustellen.

Ich hab vor ein paar Jahren eine Cocoa-Applikation geschrieben, die sehr umfangreiche Zahlenanalysen durchgeführt hat. Diese Anwendung war übrigens auch der Grund, weshalb ich überhaupt mit Cocoa angefangen habe. Die Applikation war multithreaded, musste mehrere Milliarden Objekte anlegen und natürlich auch wieder frei gegeben. Geleakt hat da nie irgend etwas. Ganz so falsch kann Aaron Hillegass das Memory Management also nicht beschrieben haben.

Man merkt, dass du von etwas sprichst, was du nicht gelesen hast. Dazu sogleich:

Überflogen heißt nicht "nicht gelesen". Ich habe die Beispiele nicht gemacht und - das gebe ich auch gerne zu - manche Bereiche nur quergelesen. Das liegt aber daran, dass ich das Buch nur zur Auffrischung gekauft habe. Außerdem hätte ich das Buch nicht wirklich benötigt und wollte - wie auch schon erwähnt - durch meinen Kauf die Autoren unterstützen. Ich bin wie gesagt kein Neueinsteiger. Wie erwähnt habe ich jahrelang WebObjects Anwendungen geschrieben. Sehr erfolgreich übrigens. Es bringt mir also nicht sehr viel, Kapitel über Bedingungen, Schleifen, Operatoren, Grundlagen der Objektorientierung oder über Collections zu lesen.

Es war ein Fehler überhaupt zu erwähnen, dass ich die ersten Kapitel nur "überflogen" habe. Daran hängst Du Dich in Deiner Argumentation auf. Da ich diese Kapitel nicht gelesen habe, unterstellst Du mir grobe Unkenntnis. Noch einmal: ich habe das überflogen, weil ich diese Kenntnisse schon habe.

Aber immerhin wird man darauf hingewiesen, weil das Programm nicht funktioniert.

Das Problem dabei ist nur, dass der Leser den Fehler natürlich zuerst bei sich selbst sucht. Wenn das nur ein Einzelfall wäre, wäre es auch kein so großes Problem. Im wiederholten Falle führt das aber auch sehr schnell zu Frust.

Bei den Memory Leaks sieht alles ordnungsgemäß aus.

Dafür gibt es aber MallocDebug, ObjectAlloc und OmniObjectMeter. Wirklich gefeit ist niemand vor Leaks. Wenn man aber diese Tools verwendet, wird man aber die meisten davon sicher finden. Vielleicht wären sie auch eine Erwähnung im Buch wert?

a) Man macht einfach Methoden nicht öffentlich, indem man sie *nicht* in den Header schreibt. Dein Vorschlag, alle da herein zu schreiben und dann wieder mit Kategorien heraus zu nehmen, ist von hinten durch die Brust ins Auge: Erst ein Problem schaffen, welches ich dann beseitige.

Hier hast Du mich leider ganz falsch verstanden. Vielleicht habe ich das auch nicht differenziert genug dargestellt. Grundsätzlich ist es schlechter Stil, Methoden nicht zu deklarieren. Die Deklaration erfolgt normaler Weise im Header-File. Wenn man die Internas der Klasse aber nicht öffentlich machen will, existiert noch eine zweite Möglichkeit: die Methoden im Implementation-File als Category zur Klasse zu deklarieren. Man erreicht dadurch keine "wirklichen privaten Methoden", kann aber zumindest die Deklaration verbergen. Dies ist übrigens eine recht verbreitete Technik, auch wenn es ins Kapitel "Dirty Tricks" fällt. Nachzulesen übrigens auch in "Objective-C Pocket Reference" von O'Reilly - oder ist das auch ein schlechtes Buch? Zitat aus diesem Buch (Seite 21):

"Because the compiler needs to know parameter types to generate method calls, you should also not omit method declarations in attempt to make them private."

Beides zu machen - sowohl im Header deklarieren und zusätzlich auch noch eine Category einzuführen - ist tatsächlich ziemlicher Unsinn. So war es von mir aber auch nicht gemeint.

b) Das hat dann keine Auswirkungen auf die Übersetzungszeit.

Selbst wenn es keine Auswirkung auf die Übersetzungszeit hätte, ergibt sich dadurch noch ein anderes Problem. Man muss bei der Implementation sehr auf die Reihenfolge der Methoden achten. Wird in einer Methode eine zweite aufgerufen, die nicht davor implementiert wurde, führt das zu einer Warning. Es ist und bleibt schlechter Stil auf Methodendeklarationen zu verzichten - besonders in einem Lehrbuch.

b) Was passiert denn? Wenn du mit Underscores arbeitest, gibt es einen Übersetzungsfehler, den du beseitigen musst. Wenn du ohne Underscore arbeitest, dann gibt es *keinen* Übersetzungsfehler, das Programm funktioniert jedoch äußerst wundersam.
na, was hältst du für besser? Fröhliche Ferhlersuche!

Deine Argumentation geht leider ins Leere. Ich beziehe mich hier auch auf Deine "Sachargumente". Einen Übersetzungsfehler gibt es nur dann, wenn ich das Programm neu übersetze. Leider treten die Schwierigkeiten meist erst beim Kunden, zum Beispiel nach einem Systemupdate, auf und plötzlich funktioniert das Programm "äußerst wundersam". Da hat man sich dann klassisch selbst ein Bein gestellt.

Das von Dir beschriebene "Fragile-Baseclass-Problem" ist ein Problem, welches es in allen objektorientierten Sprachen gibt. Du hast es auch recht schön anhand Deines Beispiels beschrieben. Einen wirklichen Schutz dagegen gibt es aber nicht. Wenn man sich jedoch mit Design Patterns auseinander setzt, lernt man sehr schnell ein ganz wesentliches Entwurfsprinzip - das "Open-Closed-Principle". Dies besagt, dass Komposition meist der Vererbung vorzuziehen ist. Außerdem sollte man auf eine Schnittstelle und nicht auf eine Implementierung entwickeln. Dadurch ist das Risiko mit einem "Fragile-Baseclass-Problem" kämpfen zu müssen stark reduziert. Das steht übrigens auch beim Wikipedia-Eintrag zu diesem Problem:

"Also, in general, programmers should program to interfaces rather than concrete implementations."

Das Fragile-Baseclass-Problem löst man daher durch den Einsatz von Mustern, wie zum Beispiel das "Strategy-Pattern" oder das "PlugIn-Pattern" und nicht durch die Verwendung einer "Underscore-Notation".

Es mag schon sein, dass man manchmal Regeln brechen muss. Vorher sollte man aber die Regeln lernen, damit man dann wenn man sie bricht, die Folgen abwägen kann. Vor allem weiß man dann, dass man eine Regel bricht. Neueinsteigern gleich einen Regelbruch als Regel beizubringen halte ich für falsch. In Deinem Buch schreibst Du dazu:

"Apple selbst empfiehlt dies, jedoch mit dem Unterschied, dass der Unterstrich weggelassen werden soll. Entscheiden Sie selbst."

Das halte ich für wenig hilfreich für einen Einsteiger. Eigenartiger Weise haltet Ihr Euch im Buch auch nicht durchgängig an diese Notation und du bist - wie Du selbst schreibst - auch schon davon abgekommen. Welchen Vorteil hat es Deiner Ansicht nach Attribute mit Großbuchstaben anzufangen? Das kommt in dem Buch auch vor.

Wir können natürlich ewig darüber weiter diskutieren und du wirst immer wieder Beispiele finden, wieso es eine besonders gute Idee ist entgegen der ausdrücklichen Empfehlung Apples genau diese Notation zu verwenden. Vielleicht können wir uns aber darauf einigen, dass Gamma, Helm, Vlissides und Johnson (GoF) wissen, wovon sie schreiben, wenn es um Design Patterns zur Umgehung des "Fragile-Baseclass-Problem" geht.

[gleich gehts weiter] ;)
 
Zuletzt bearbeitet:

zirpl

Golden Delicious
Registriert
28.09.07
Beiträge
10
a) KVC und KVO (das meinst du wohl, mit Bindings selbst hat das ziemlich genau gar nichts zu tun) suchen zuerst nach Accessoren. Da in sämtlichen Fällen entsprechende Accessoren vorhanden sind, kann für KVC und KVO die Instanzvariable heißen wie sie will. ...

Da ich - wie schon erwähnt - meine Brötchen sehr lange mit WebObjects verdient habe, habe schon ein klein Wenig Ahnung von KVC. Mir ist schon klar, dass zuerst nach Accessoren gesucht wird. Es ist halt eine weitere mögliche Fehlerquelle, die man im Sinne der Softwarequalität vermeiden sollte.

Es sei nur nebenbei bemerkt, dass es sowohl nach Instanzvariablen mit und ohne Underscore sucht.

Okay. Das war mir nicht bewusst. Mein Fehler.

Dieser Hinweis zeugt von grober Unkennntnis. In keinem einzigen Fall werden Keys verwendet, die mit einem Underscore beginnen. Es werden Instanzvariablen mit Underscore verwendet. Dies ist *nicht* das gleiche.

Aus ""Cocoa Fundamentals Guide: Basic Subclass Design":

"Key-value coding (KVC), through an implementation of the NSKeyValueCoding informal protocol, makes it possible to get and set the values of an object’s properties through keys without having to invoke that object’s accessor methods directly. (Cocoa provides a default implementation of the protocol.) A key typically corresponds to the name of an instance variable or accessor method in the object being accessed."

Es stimmt schon - es ist nicht das Gleiche. Es ist aber üblich Keys gleich wie Attribute zu bezeichnen.

Du hast hier dringenden Nachholbedarf, was KVC und KVO angeht.(Mit Bindings hat das immer noch nichts zu tun, was auf weiteren Nachholbedarf schließen lässt.)

Ich zitiere mal kurz aus "Cocoa Fundamentals Guide: Bindings":

"The implementation of bindings rests on the enabling mechanisms of key-value coding, key-value observing, and key-value binding. See “Key-Value Mechanisms” for overviews of these mechanisms and their associated informal protocols."

Die Dichte deiner Fehler in diesem Beitrag werden sicherlich vom Buch nicht erreicht. Es zeigt aber auch, und das ist wesentlicher, dass die von dir zitierte Lektüre das offenbar nicht, fehlerhaft oder nur rudimentär vermittelt hat. Du hast damit ein wunderbares Gegenargument geliefert. Danke!

Sorry, wer als jahrelanger Programmierer wie zirpl das nicht weiß, obwohl er drei Standardwerke gelesen hat, macht entweder etwas falsch oder die Standardwerke. Jedenfallls ist es so, wie ich es schreibe, richtig.

Ich halte es indessen immer noch für deutlich schlechter, wenn jemand nach der Lektüre von drei Standardwerken Grundtechnologien von Cocoa nicht verstanden hat und dies nicht bemerkt.

Sorry, er hat davon keine Ahnung.

BTW: Wenn habe ich denn zuerst persönlich angegriffen? verteidigen darf ich mich doch mit gleicher Waffe, oder?

Sag mal - was ist mit Dir los? Ich habe in meinem Posting ausdrücklich geschrieben, dass ich in keinster Weise an Deiner fachlichen Kompetenz zweifle. Ganz im Gegenteil habe ich geschrieben, dass ich Deine Kompetenz sehr schätze. Ich habe ein Problem beim Qualitätsmanagement vermutet.

Du übersiehst eine Sache offensichtlich völlig. Ich bin Dein Kunde! Ich habe für Dein Buch Geld ausgegeben und bin offensichtlich nicht zufrieden damit. Als Antwort sagst Du mir, ich sei einfach zu Dumm dafür. Das nenne ich mal einen interessanten Kundenumgang.

Ich verdiene meinen Unterhalt seit vielen Jahren mit Software-Entwicklung. Danke, dass Du mir meine Fähigkeit dazu absprichst.

Noch BTW: Bemerkenswert finde ich noch, dass du mich offenbar kennst, du dir aber extra für diesen Beitrag einen neuen Account zugelegt hast. Im Entwicklerforum gibt es auch gerade zwei Beiträge in einem Thread von dir, der zudem nicht zum Cocoa-Forum gehört.

Ich bin ein reger Foren-Besucher, aber meist passiv. Ich bin im Entwicklerforum ein Stammgast. Ich hatte einmal eine technische Frage und habe mich daher angemeldet. Diese Frage wurde mir schnell und kompetent beantwortet, ich habe mich bedankt und das wars. Auch dieses Forum besuche ich regelmäßig. Macht es mich jetzt zu einem schlechteren Benutzer, weil ich erst heute einen Grund sah mich anzumelden um etwas zu posten?

Dein Buch ist einfach nicht gut. Tut mir leid, so sehe ich das. Traurig ist, dass das Buch wirklich Potential gehabt hätte. Du hängst Dich hier an der Underscore-Notation (und KVC) auf und schreibst Dir Die Finger wund, damit wohl alle hier erkennen, wie dämlich der Foren-Neuling ist und dass Du der schlaueste hier bist. Zum extrem fehlerhaften Drag & Drop Beispiel sagst Du aber nichts. Ach ja. Das geht Dich ja nichts an. Warum steht dann Dein Name am Einband?

Sorry, mir ist ziemlich gleichgültig, ob das Apple, Gott, Hillegass, Schmitz oder Müller propagieren.
[...] Jedenfallls ist es so, wie ich es schreibe, richtig.

Damit disqualifizierst Du Dich selbst. Kurz gesagt: Du machst alles richtig und wer das in Frage stellt hat einfach keine Ahnung. Aaron Hillegass, Steven Kochan, Andrew Duncan und Mark Dalrymple sind offensichtlich Stümper. Eigenartiger Weise hatte ich keinerlei Probleme mit den Beispielen in deren Büchern. Auch Apple schreibt deiner Meinung nach Unsinn in die Entwicklerdokumentation. Sogar Gott ist im Vergleich zu Dir ahnungslos.

Wie gesagt bin ich nach über 20-jähriger beruflicher Software-Entwicklung auch kein Frischling mehr. Außerdem muss ich mich hier sicher nicht persönlich beleidigen lassen.

Gruß
Christian
 
Zuletzt bearbeitet:

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Es war ein Fehler überhaupt zu erwähnen, dass ich die ersten Kapitel nur "überflogen" habe. Daran hängst Du Dich in Deiner Argumentation auf. Da ich diese Kapitel nicht gelesen habe, unterstellst Du mir grobe Unkenntnis. Noch einmal: ich habe das überflogen, weil ich diese Kenntnisse schon habe.
Es war ein Fehler, sie nur querzuelesen und dennoch darüber zu schreiben. Nach einen Bekundungen hast du die ersten Kapitel (1 bis 5) nur quergelesen, drei gelesen und die weiteren ab 9 gar nicht mehr gelesen. Du hast also exakt drei Kapitel gelesen.

Ferner hast du die ersten Kapitel überflogen, weil es "für dich nichts mehr zu lernen gab". Dann machst du exakt Fehler, die du nicht machen würdest, wenn du sie gelesen hättest. Es sei hier nur die Methodendeklaration im Header genannt.

Dann zu sagen, dass es ein Fehler sei, das zuzugeben, schlägt echt dem Fass den Boden aus. Nein, es ist kein Fehler, dass du von etwas schreibst, was du nicht gelesen hast. Der Fehler liegt darin, dies zuzugeben. *Bravo!*

Das Problem dabei ist nur, dass der Leser den Fehler natürlich zuerst bei sich selbst sucht. Wenn das nur ein Einzelfall wäre, wäre es auch kein so großes Problem. Im wiederholten Falle führt das aber auch sehr schnell zu Frust.
Sorry, bei den allen meisten Fehlern, liegt die Ursache völlig auf der Hand.

Dafür gibt es aber MallocDebug, ObjectAlloc und OmniObjectMeter. Wirklich gefeit ist niemand vor Leaks. Wenn man aber diese Tools verwendet, wird man aber die meisten davon sicher finden. Vielleicht wären sie auch eine Erwähnung im Buch wert?
Wenn man sich an die Handwerksregeln hält, ist man davor ziemlich gefeit. Übrigens gebe ich Tipps zum Suchen von Memory Leaks. Du hättest vielleicht das richtig lesen sollen. Übrigens: Ich gebe lieber Tipps im Buch, die man *nicht* in dem Ordner Tools findet, als mit derlei Hinweisen die Seiten zu füllen. Ich halte es nämlich für sinnvoll, etwas zu schreiben, was man ansonsten nicht an Information hat.

Ich weiß, dass das andere anders sehen.

Hier hast Du mich leider ganz falsch verstanden. Vielleicht habe ich das auch nicht differenziert genug dargestellt. Grundsätzlich ist es schlechter Stil, Methoden nicht zu deklarieren.
Sorry, das ist Unfug. Eine Forward ist aus zwei Gründen erforderlich:

a) Man will etwas bekannt machen und der andere hat nur den Header.

b) Man muss es wegen wechselseitiger Beziehungen machen.

Es gibt ansonsten keinen Grund, etwas vorher zu forwarden, weil eine Definition stets eine Deklaration impliziert. Eine explizite Deklaration ist nur schlecht wartbar, führt zu Fehlern und ist "doppel gemoppelt".


Die Deklaration erfolgt normaler Weise im Header-File
Das ist falsch. Die Deklaration erfolgt im Header-File, wenn Sie publik gemacht werden soll. Dann und nur dann.

Wenn man die Internas der Klasse aber nicht öffentlich machen will, existiert noch eine zweite Möglichkeit: die Methoden im Implementation-File als Category zur Klasse zu deklarieren. Man erreicht dadurch keine "wirklichen privaten Methoden", kann aber zumindest die Deklaration verbergen. Dies ist übrigens eine recht verbreitete Technik, auch wenn es ins Kapitel "Dirty Tricks" fällt. Nachzulesen übrigens auch in "Objective-C Pocket Reference" von O'Reilly - oder ist das auch ein schlechtes Buch? Zitat aus diesem Buch (Seite 21):

"Because the compiler needs to know parameter types to generate method calls, you should also not omit method declarations in attempt to make them private."

Beides zu machen - sowohl im Header deklarieren und zusätzlich auch noch eine Category einzuführen - ist tatsächlich ziemlicher Unsinn. So war es von mir aber auch nicht gemeint.
Es gibt noch eine dritte Möglichkeit: Man deklariert sie gar nicht explizit. Das kann man sich nämlich sparen, wenn man sie definiert. Weil wie gesagt, jede Definition eine implizite Deklaration ist.

Dies wird übrigens ebenfalls n den von dir quergelesenen Kapiteln ausgeführt.

Selbst wenn es keine Auswirkung auf die Übersetzungszeit hätte, ergibt sich dadurch noch ein anderes Problem. Man muss bei der Implementation sehr auf die Reihenfolge der Methoden achten. Wird in einer Methode eine zweite aufgerufen, die nicht davor implementiert wurde, führt das zu einer Warning. Es ist und bleibt schlechter Stil auf Methodendeklarationen zu verzichten - besonders in einem Lehrbuch.
Man muss überhaupt nicht auf die Reihenfolge achten. Man fängt mit den Accessoren an, die primitiv sind. Dann baut man die Funktionalität drauf, da diese die Accessoren benötigen. Dann kümmert man sich um Instantierung pp. da diese wiederum potentiell alles benötigen.

In dem Buch gibt es IIRC keine einzige Notwendigkeit für einen Forward. Zufall? Nein, sondern System namens "Bottom-Up". Das sorgt auch gleich für Ordnung im Code, weil es nunmehr nicht möglich ist, mal irgendwo etwas reinzupinseln. Ich halte das für Vorteilhaft.

Übrigens wird auch das erläutert in den Kapitel, die dir nichts Neues bringen, was du schon weißt, als du es quergelesen hast. Hättest du es mal richtig gelesen. Dann müsste ich das alles nicht mehr schreiben. Es steht nämlich bereits im Buch.

Deine Argumentation geht leider ins Leere. Ich beziehe mich hier auch auf Deine "Sachargumente". Einen Übersetzungsfehler gibt es nur dann, wenn ich das Programm neu übersetze. Leider treten die Schwierigkeiten meist erst beim Kunden, zum Beispiel nach einem Systemupdate, auf und plötzlich funktioniert das Programm "äußerst wundersam". Da hat man sich dann klassisch selbst ein Bein gestellt.
Bei keiner Verwendung von Underscores verhält es sich wundersam. Ich habe das später ausargumentiert und mit Code belegt. Es wäre dienlich, wenn du darauf sachbezogen eingingest. Mutmaßlich hast du das aber nur quergelesen.

Das von Dir beschriebene "Fragile-Baseclass-Problem" ist ein Problem, welches es in allen objektorientierten Sprachen gibt. Du hast es auch recht schön anhand Deines Beispiels beschrieben. Einen wirklichen Schutz dagegen gibt es aber nicht.
… + andere Stellen im Beitrag …
Ich habe nicht gesagt, dass Underscores ein Schutz gegen dsa fBCP sind, sondern, dass es sich um einen solchen Fall handelt.

Ich habe gesagt und gezeigt, dass Underscores für einem bestimmten Untertypus schützen, weil ich nach einer einfachen Neucompilierung gleich vom Übersetzer eine Liste der Probleme bekomme. Nein, die muss auch nicht vollständig sein. Es gibt abgefahrene Situationen. Sie ist aber eben auch nicht leer: Ich nutze also etwas, um Fehler zu finden. Das finde ich vorteilhaft.

Umgekehrt führt der Vorschlag von Apple dazu, dass man sie garantiert nicht findet und sich das Programm nicht nachvollziehbar verhält. Ich habe das ganze ausargumentiert und belegt.

Ich bringe auch nicht einen Regelbruch bei, sondern überlasse das dem Leser. Die Gründe dürfte ich ausreichend dargelegt haben.


Da ich - wie schon erwähnt - meine Brötchen sehr lange mit WebObjects verdient habe, habe schon ein klein Wenig Ahnung von KVC. Mir ist schon klar, dass zuerst nach Accessoren gesucht wird. Es ist halt eine weitere mögliche Fehlerquelle, die man im Sinne der Softwarequalität vermeiden sollte.
Wieso ist es eine weitere mögliche Fehlerquelle n Bezug auf KVC und KVO?



Aus ""Cocoa Fundamentals Guide: Basic Subclass Design":

"Key-value coding (KVC), through an implementation of the NSKeyValueCoding informal protocol, makes it possible to get and set the values of an object’s properties through keys without having to invoke that object’s accessor methods directly. (Cocoa provides a default implementation of the protocol.) A key typically corresponds to the name of an instance variable or accessor method in the object being accessed."

Es stimmt schon - es ist nicht das Gleiche. Es ist aber üblich Keys gleich wie Attribute zu bezeichnen.
Und zwar sowohl mit wie ohne Underscore. Sämtliche Cocoa-Klassen benutzen nämlich den Underscroe.

Ich zitiere mal kurz aus "Cocoa Fundamentals Guide: Bindings":

"The implementation of bindings rests on the enabling mechanisms of key-value coding, key-value observing, and key-value binding. See “Key-Value Mechanisms” for overviews of these mechanisms and their associated informal protocols."
Exakt das habe ich geschrieben: Bindings treten überhaupt nicht mit meinem Objekt in Kontakt, sondern überlassen das KVC und KVO. Daher kann *nichts* was mit KVC und KVO funktioniert, irgendwie Bindings stören. Sie haben damit schlicht nichts zu tun. (Wird im nächsten Beitrag ausgeführt) Bindings sind nämlich ein Protokoll zur einrichtenden Klasse hin, nicht zur observierten. Es existiert ganz genau keine einzige Methode innerhalb der Bindings-Technologie, die auf das observierte Objekt zugreift. Aber das ist sicherlich alles in den drei Standardwerken genausten aufgeführt.

Sag mal - was ist mit Dir los? Ich habe in meinem Posting ausdrücklich geschrieben, dass ich in keinster Weise an Deiner fachlichen Kompetenz zweifle. Ganz im Gegenteil habe ich geschrieben, dass ich Deine Kompetenz sehr schätze. Ich habe ein Problem beim Qualitätsmanagement vermutet.
Es geht nicht um mich, es geht ums Buch. Es geht zudem darum, dass du hierzu Behauptungen aufstellst, obwohl du nach deiner eigenen Aussage es überhaupt nicht richtig gelesen hast. Offenkundig nicht einmal das Inhaltsverzeichnis. Hinzukommt, dass du Kritikpunkte aufstellst, die schlicht nicht zutreffen und zeigen, dass das Verhältnis von KVC, KVO, Bindings Schlüsseln und Instanzvariablen von dir - immer noch sorry - überhaupt nicht begriffen wurde. Dann kann deine Literaturempfehlung nicht soooo gut gewesen sei. (Natürlich sind die Bücher wichtig. Aber sie erklären Kerntechnologien von Cocoa teilweise nur ansatzweise.)

Du übersiehst eine Sache offensichtlich völlig. Ich bin Dein Kunde! Ich habe für Dein Buch Geld ausgegeben und bin offensichtlich nicht zufrieden damit. Als Antwort sagst Du mir, ich sei einfach zu Dumm dafür. Das nenne ich mal einen interessanten Kundenumgang.
Ich habe nicht gesagt, dass du dumm seist. Ich habe sogar in einem Beitrag geschrieben, dass man exakt diese Fehler im Verständnis im halben Internet findet. Und ich habe geschrieben, dass ich irgendwann mal bemerkte woher sie stammen. Diese Dinge sind in der von di empfohlenen Lektüre, wenn überhaupt, nur miserabel besprochen. Der Punkt ist: Das fällt keinem auf. Die Leser glauben, dass sie es verstanden hätten.

Übrigens beziehe ich zu deinen Behauptungen Stellung oder nicht. Ich werde das bestimmt nicht davon abhängig machen, ob du das Buch gekauft hast. Entscheidend finde ich es allerdings, ob du es gelesen hast. Und das ist ja nach deinen eigenen Bekundungen nicht der Fall.

Ich verdiene meinen Unterhalt seit vielen Jahren mit Software-Entwicklung. Danke, dass Du mir meine Fähigkeit dazu absprichst.
Ich habe dir nicht deine Fähigkeiten zur Software-Entwicklung abgesprochen. Ich habe dir deine Fähigkeiten zu KVC, KVO und Bindings abgesprochen. Und dazu stehe ich auch.


Ich bin ein reger Foren-Besucher, aber meist passiv. Ich bin im Entwicklerforum ein Stammgast. Ich hatte einmal eine technische Frage und habe mich daher angemeldet. Diese Frage wurde mir schnell und kompetent beantwortet, ich habe mich bedankt und das wars. Auch dieses Forum besuche ich regelmäßig. Macht es mich jetzt zu einem schlechteren Benutzer, weil ich erst heute einen Grund sah mich anzumelden um etwas zu posten?
Nein, das macht es nicht. Nur: Offenbar kennst du mich aus Foren besser und länger. Umgekehrt ist das nicht so. Da hätte ich schon gerne Genaueres zu gewusst. Es ist ja in solchen Fällen auch nicht unüblich, sich vorzustellen.

Dein Buch ist einfach nicht gut. Tut mir leid, so sehe ich das.
Du solltest es vielleicht zuerst lesen.

Traurig ist, dass das Buch wirklich Potential gehabt hätte. Du hängst Dich hier an der Underscore-Notation (und KVC) auf und schreibst Dir Die Finger wund, damit wohl alle hier erkennen, wie dämlich der Foren-Neuling ist
Nein, ich habe nicht nur dazu geschrieben.

a) Ich habe generell zum Verhältnis von KVC, … geschreiben.

b) Ich habe dazu geschrieben, dass das gerade *nichts* mit der Notierung zu tun hat.

c) Ich habe auch zu ganz anderen Themen geschrieben, auch zustimmend.
- Etwa zu Headern, nicht zustimmend.
- etwa zu acceptsFirstResponder, zustimmend.

Wenn du schon am Buch kritisierst, obwohl du es nicht gelesen hast, solltest du wenigstens meine Beiträge hier lesen.

und dass Du der schlaueste hier bist. Zum extrem fehlerhaften Drag & Drop Beispiel sagst Du aber nichts.
Doch dazu habe ich etwas geschrieben. Schau noch einmal nach.

Ich behaupte auch nicht, dass ich der Schlauste bin. Ich behaupte jedoch, dass du das Buch nicht gelesen hast und es trotzdem beurteilst. Ich behaupte ferner, dass deine Kritik zu den Ausführungen zu KVC, … fehlerhaft ist. Genau das. Nicht mehr und nicht weniger.

Ach ja. Das geht Dich ja nichts an. Warum steht dann Dein Name am Einband?
Es geht mich etwas an. Ich werde aber nicht anderer Leute Arbeit kommentieren, ohne mich da eingelesen zu haben. Das ist übrigens eine ganz gute Methodik.


Damit disqualifizierst Du Dich selbst.
Sorry, disqualifiziert hast du dich. WEr so etwas schreibt wie:

"Die ersten Kapitel habe ich nur überflogen und den Rest dann gar nicht mehr gelesen, aber das ist alles schlecht," um dann Fehler zu machen, die man nicht machen würde, wenn man das Buch gelesen hätte … Das ist schon unterirdisch.

Kurz gesagt: Du machst alles richtig
Das ist nicht richtig. Ich hatte mehrfach Fehler eingestanden. Wieso nimmst du das nicht zur Kenntnis?

und wer das in Frage stellt hat einfach keine Ahnung.
Nein, wer behauptet, dass die Instanzvariablenbezeichnung etwas mit KVC, … zu tun habe, der hat keine Ahnung von KVC, … Exakt *das* habe ich gesagt. Nicht mehr oder weniger.

Eine alte Weisheit besagt, dass man sich selbst nicht besser macht, indem man andere schlechter macht. Ich halte das im Gegenteil für eine sehr schwache Argumentation. Aaron Hillegass bringt als Entwickler der sowohl bei NeXT als auch bei Apple gearbeitet hat eine äußerst gute Reputation mit. Natürlich macht auch er Fehler. Es zeugt jedoch von sehr großem Selbstbewusstsein, ihn als Stümper hinzustellen.
Aaron Hillegass, Steven Kochan, Andrew Duncan und Mark Dalrymple sind offensichtlich Stümper.
Das hatte ich nicht gesagt. Wieso behauptest du so etwas? Ich hatte gesagt, dass sie es offenkundig nicht schaffen, Speicherverhaltung und KV-Technologien dem Leser beizubringen. Und das stimmt ganz offensichtlich.

Eigenartiger Weise hatte ich keinerlei Probleme mit den Beispielen in deren Büchern.
Das schrieb ich schon. Die Leute halten das falsch Gelernte auch noch für richtig. Wenn sie allerdings sich einmal die Speicherbelegung der so erzeugten Programme anschauen, werden sie was bemerken. Mach doch einfach mal!

Auch Apple schreibt deiner Meinung nach Unsinn in die Entwicklerdokumentation. Sogar Gott ist im Vergleich zu Dir ahnungslos.
Ich hatte gesagt, dass mir gleichgültig, *wer* etwsa schreibt. Ich hatte stattdesen meine Behauptung ausargumentiert und mit Code belegt.

Wenn deine Antwort ist: "Die sagen das aber doch!", dann bist du eben mehr Personalien als Sachargumenten zugänglich.

Wie gesagt bin ich nach über 20-jähriger beruflicher Software-Entwicklung auch kein Frischling mehr. Außerdem muss ich mich hier sicher nicht persönlich beleidigen lassen.
Sic!
 
Zuletzt bearbeitet:

Sigur

Adams Parmäne
Registriert
10.07.06
Beiträge
1.301
und welches buch soll ich mir jetzt kaufen?
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
(Weiterer Beitrag)
Du hast offensichtlich das System von KVC, KVO und Bindings immer noch nicht verstanden.

Die grobe Struktur habe ich hier gezeichnet:
http://cocoading.de/Sonstiges/Bindings.jpg

Das Bindings-Creattion Protokolles umfasst folgende Methoden.
+ exposeBinding:
– exposedBindings
– valueClassForBinding:
– bind:toObject:withKeyPath:oops:ptions:
– infoForBinding:
– unbind:

Gehen wir das einmal durch:
+ exposeBinding:
ist eine Methode, die vom Implementierer (mittleres Objekt) benutzt wird . Sie hat also nichts mit dem Observierten zu tun, geschweige denn mit dessen Accessoren, noch geschweige denn mit dessen Instanzvariablen. Sie bezieht sich gar nicht auf den Observierte.

– exposedBindings
ist eine Methode, die Implementierer (mittleres Objekt) überschrieben werden kann. Sie hat also nichts mit dem Observierten zu tun, geschweige denn mit dessen Accessoren, noch geschweige denn mit dessen Instanzvariablen. Sie bezieht sich gar nicht auf den Observierten.

– valueClassForBinding:
ist eine Methode, die Implementierer (mittleres Objekt) überschrieben werden kann und vom Einrichter benutzt wird. Sie hat also nichts mit dem Observierten zu tun, geschweige denn mit dessen Accessoren, noch geschweige denn mit dessen Instanzvariablen. Sie bezieht sich gar nicht auf den Observierten.

– bind:toObject:withKeyPath:oops:ptions:
ist eine Methode, die Implementierer (mittleres Objekt) überschrieben werden kann und vom Einrichter benutzt wird. Sie hat also nichts mit dem Observierten zu tun, geschweige denn mit dessen Accessoren, noch geschweige denn mit dessen Instanzvariablen. Sie bezieht sich gar nicht auf den Observierten.

– infoForBinding:
ist eine Methode, die Implementierer (mittleres Objekt) überschrieben werden kann und vom Einrichter und vom Implementierer benutzt wird. Sie hat also nichts mit dem Observierten zu tun, geschweige denn mit dessen Accessoren, noch geschweige denn mit dessen Instanzvariablen. Sie bezieht sich gar nicht auf den Observierten.

– unbind:
Gegenstück zu gerade

*Keine* *einzige* Methode des Binding-Protokolles bezieht sich überhaupt nur entfernt auf den Observierten. Das ist die Grobstruktur von Bindings. Das hast du nicht ansatzweise verstanden.

Und:

a) Nein, das hat nicht damit zu tun, dass du dumm bist.

b) Ja, diesen Irrtum gibt es zahlreich. Viele denken sich das so. Das spricht gegen eine Dummheit von dir.

c) Es spricht stark dafür, dass die von dir zitierten Standardwerke das schlicht nicht oder schlecht vermitteln.

Und ja: Das bemerkt der Leser nicht. Er hat weiterhin seine falsche Vorstellung und hält die weiterhin für richtig. Wie gesagt: Du bist wahrlich nicht der einzige. Es liegt daran, dass die Leute in den von dir zitierten Werken das nicht anständig beigebracht bekommen.

(Übrigens mache ich das auch nicht intensiv genug. Das wird auch erweitert werden. Aber wenigstens deute ich es an und bringe den Leser nicht auf die falsche Spur.)