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!