Nein, das ist in der Tat keine gute Ausrede. Nichtsdestotrotz kommen 95 % der Leser darüber hinweg.
Die Code-Passagen sind übrigens das größte Problem. Das Buch geht durch ein Lektorat und ein Korrektorat. Da tippen das also Leute ab, Und was machen sie meistens? Richtig, sie tippen es intuitiv richtig ab.
Diese "Selbstverbesserung" ist überhaupt das größte Problem. In dem Wort thisObjectForRelesing liest kaum einer einen Fehler, schon gar nicht nach 400 Seiten -- nur der Compiler. Es ist übrigens ganz "lustig", dass es in der ersten Auflage Fehler gab, die nie entdeckt worden sind (Die Textstellen sind also einige 100 bis einige 1000 Male gelesen worden) und es in der zweiten Auflage deshalb Bugreports gab. Da liegste nieder …
+++
Jepp, ich muss mal wieder ein Update von der Errate-Seite machen. Ich baue bloß den gesamten Auftritt ganz neu auf. Eines der größten Seitenprobleme war es übrigens, die Struktur der Errata hinzubekommen. Ursprünglich hatte ich es einfach seitenmäßg. Dann bekam ich bloß Hinweise, dass noch einer gefunden worden wäre, der schon notiert war. Also habe ich es nach "Güte" strukturiert. Funktioniert aber auch nicht richtig.
Ich weiß auch nicht mehr, wie man es am besten macht.
Vielleicht hat sich bloß niemand die Mühe gemacht diese Bugs zu melden? Bei so offensichtlichen Sachen wie einer
2 anstatt eines Anführungszeichen ist klar, daß vergessen wurde die Shift Taste zu drücken. Auf solche Fehler kommt man schnell drauf, korrigiert sie und macht weiter. (Kapitel 3, p 116, NSException)
Bei anderen Bugs sieht das anders aus. (Kapitel 3, p 119, oben) Dort wurde ein "_" im Quellcode vergessen. Dort wirft der Compiler keinen Error und kein Warning, aber das Programm funktioniert nicht so wie es soll.
[keyCount release]; ist abgedruckt wohingegen
[_keyCount release]; abgedruckt sein sollte. Ein Bug den man
etwas länger suchen kann.
Wie gesagt, manche Fehler sind
offensichtlich aber trotzdem mehr als unnötig und obwohl sie sich durchaus selbst korrigieren lassen, sorgen sie doch beim Probanden für Frust.
Liegt es an mir? Liegt es am Compiler? Ist es ein Tippfehler? Aber hier steht doch exakt das selbe. Trotzdem funktioniert es nicht. Das hält den jungen Padawan nicht nur unnötig auf, sondern es verunsichert auch.
Wenn solche Fehler durch die Lektoren und Korrektoren relevante Teile des Buches essentiell verschlimmbessern, dann sind sie leider für diese Aufgabe im Kontext eines Programmierlehrbuches ungeeignet. Dies mag durchaus ein Verlagsinternes Problem sein, welches aber angesprochen gehört. Immerhin wirkt das der Qualität ironischerweise diametral entgegen.
Ungeachtet dessen ob Cocoa:ding nach Drucklegung der 2. Auflage entstanden ist, sollte in der 3. Auflage präventiv ein prominenter Hinweis auf die Errata im Vorwort positioniert werden. Auch damit der geneigte Leser weis wohin er gehen kann um einen vermuteten Bug zu suchen und eine Korrektur vorzufinden oder eben um einen noch nicht verzeichneten Bug melden zu können.
Mein Vorschlag für die Errata wäre diese nach Kapiteln aufzulisten, da anzunehmen ist, daß ein Leser das Buch doch eher von vorne nach hinten sequentiell durchackern wird. Innerhalb der Kapitel ist eine Auflistung nach Druckseiten wahrscheinlich die sinnvollste Referenz wo man dann als Vergleich die abgedruckte Textpassage und die korrigierte Passage vorfinden möge. Ganz wichtig wäre hier eine
Hervorhebung der Änderungen.
(Etwas was mir bei den abgedruckten Listings auch immer wieder abgegangen ist. "Nehmen wir nun das Beispiel von vorhin und ändern den Code ab, damit
dies dort steht. <unheimlichLangesCodeListing> Mangels Hervorhebung der Neuerungen muß man mühsam Zeile für Zeile vergleichen anstatt zügig weiterlernen zu können.)
Praktisch wäre natürlich auch eine Suchfunktion wo man einfach die Seitennummer eingeben kann und dann die entsprechenden Errata aufgelistet bekommt. Zusätzlich sollte man dort auch gleich die Möglichkeit haben einen neuen Bug melden zu können. (Dann tun die User das nämlich auch, weil es bequem ist.)
Gruß Pepi