- Registriert
- 27.12.06
- Beiträge
- 1.477
Eine Klasse ist also ein Bauplan, stimmts auch wenn ich Vorlage sage? Das Objekt wäre demnach die Benutzte Vorlage...
-
Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
Näheres könnt Ihr hier nachlesen: AGB-Änderung -
Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick
Methoden, Klassen, usw.
- Ersteller doeme89
- Erstellt am
zeno
Lane's Prinz Albert
- Registriert
- 05.11.05
- Beiträge
- 4.894
Das ist recht egal wenn du Vorlage sagst, solange du das Prinzip verstanden hast
Irgendwann wirst du dann eh auf die gebräuchlichen Begriffe wie Klasse, Objekt etc umschwenken. Ein gemeinsamer Wortschatz ist wichtig Genau, ein Objekt ist die benutzte/umgesetzte Vorlage.
Ja, man kann gut Vorlage sagen, wobei in Objective-C die Klasse mehrere Funktionen hat. Es ist auch besser, bei diesen Objekten, die du meinst, von Instanzen zu sprechen.
- Registriert
- 27.12.06
- Beiträge
- 1.477
Das ist recht egal wenn du Vorlage sagst, solange du das Prinzip verstanden hast
Genau, ein Objekt ist die benutzte/umgesetzte Vorlage.
Da kann ich euch beiden nur zustimmen! Genau aus diesem Grund habe ich dieses Thema angefangen, um die allgemeinen Begriffe richtig zu verstehen! In dem Fall ist es mir jetzt recht klar...
Ich habe vor mir heute Abend ein Buch zu Cocoa/Objective-C zu kaufen, und habe dazu 2 gefunden:
Buch1 Buch2
Stimmt es, dass Buch1 eine neuere Ausgabe von Buch2 ist, oder ist das was komplett anderes? Reicht mir als Anfänger (und hoffentlich bald Fortgeschrittener) Buch2 aus?
Ja, das ist eine zweite Auflage, allerdings angesichts der starken Erweiterung nur im technischen Sinne zu verstehen. Spar die paar Euro nicht.
cocoading.de ist übrigens die seite zur zweiten Auflage.
Na, die Zahl der Damenunterwäsche in meinem Briefkasten hält sich in Grenzen. Prominent ist anders.
- Registriert
- 27.12.06
- Beiträge
- 1.477
Bitte den Errata zur 2. Auflage unbedingt Aufmerksamkeit zu schenken wer mit dem Buch "Objective-C und Cocoa" lernen möchte. Die (leider) vielen (teilweise peinlichen Copy/Paste) Fehler im Buch lassen einen teilweise fast verzweifeln. Besonders dann wenn der Code garnicht mehr compilierbar ist oder zur Laufzeit abstürzt weil im Buch fehlerhafter Code abgedruckt ist. (Übt andererseits das Debuggen von Code. 
)
Wenns also mal so garnicht funktionieren will einen Blick auf die Korrekturen werfen oder im Board zum Buch im OS X Entwicklerforum schauen ob dort jemand eine Fehlerkorrektur gepostet hat.
Gruß Pepi
)Wenns also mal so garnicht funktionieren will einen Blick auf die Korrekturen werfen oder im Board zum Buch im OS X Entwicklerforum schauen ob dort jemand eine Fehlerkorrektur gepostet hat.
Gruß Pepi
Bei der Konkurrenz finden sich Fehler, die nicht auffallen. Dafür werden sie auch nicht auf der Errata-Seite angemerkt.
Ich weiß nicht, was besser ist …
Ich weiß nicht, was besser ist …
Habe das Buch gestern gekauft, und bin begeistert! Bis jetzt ist alles so wie ich es von einem "Selbststudium-Buch" erwarte: klar gegliedert, einfach und verständlich erklärt, und nicht zuerst 5 Kapitel Theorie am Anfang...
Ich hoffe, dass sich damit die Kiste mit Klassen, Objekten, Methoden usw. erledigt hat.
Nein, da ist die Konnotation eine andere.
Es gibt Prototypen Programmiersprachen (bzw. das Prototypen Entwurfsmuster) und auf einen Prototyp paßt der Begriff "Vorlage" sehr viel besser als auf "Klasse". Der entscheidende Unterschied zwischen einer Klasse und einem Prototypen ist eben, daß es von einer Klasse kein Exemplar (Objekt des Typs einer bestimmten Klasse) geben muß, um ein Exemplar erzeugen zu können. Dagegen braucht man diese Vorlage (den Prototypen eben) für das Erzeugen neuer Objekte in einer Prototypen Programmiersprache.
In Objective-C muss es ein Exemplar geben, nämlich das Klassenobjekt.
Du meinst mutmaßlich, dass die Instanz kein Abbild der Klasse ist. Das hatte er aber schon verstanden.
Du meinst mutmaßlich, dass die Instanz kein Abbild der Klasse ist. Das hatte er aber schon verstanden.
Daß "die Konkurrenz" es anders oder (noch) schlechter macht ist kein Grund dafür sich selbst nicht weiter zu verbessern. Die Errata Seite zu Deinem ist leider auch nicht vollständig.
Ich erwarte mir von einem 50€ Lehrbuch (In der 2. Edition), daß zumindest die Code Passagen fehlerfrei abgedruckt sind. Von einem Programmier-/Objective-C/Cocoa-Anfänger ist schließlich nicht zu erwarten, daß er sämtliche Compiler-Errors/Compiler-Warnings/Laufzeit-Fehler mit einem Schnipsen versteht und beheben kann.
Die chaotischen Verwechslungen von Klavieren mit Gitarren in Kapitel 3 muten da ja noch fast unterhaltsam an. Trotzdem trübt es den anfänglichen positiven Eindruck des Buches stark.
Gruß Pepi (Ja, ich habe das Buch auch gekauft.)
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
Es war kein "offensichtlicher" Bug. Ich weiß es nicht mehr, aber ich wunderte mich schwer. Aber das sagte ich ja: Solche Bugs wie " statt 2 oder namee usw. finde ich nicht schön, aber alles andere als tragisch. Die sieht man sofort und kann sie selbst verbessern. Ich glaube auch nicht, dass sich da ein Leser längere Auseinandersetzungen mit sich liefert.
Im Vorwort findet sich ein Link zum Entwickler-Forum. Dort gibt es ein eigens eingerichtetes Forum und auch den Hinweis auf cocoading.de. Ich kann da kein Problem erkennen.
Nach Kapiteln ist ja wie nach Seiten. Nur: Glaube mir, es funktioniert nicht. Ich habe da meine Erfahrungen. Und frage mich *bitte* nicht, warum. Ich weiß nur, dass ich Fehler gemailt bekommen habe, die auf der Seite noch fehlten ... Dort aber gelistet waren. Ich dachte mir dann, dass es vielleicht zu unübersichtlich ist und da die meisten Mails ohnehin Kompilierungsfehler betrafen, habe ich daraus eine Kategorie gemacht. Es sind jetzt auch weniger Mails geworden, was aber natürlich auch daran liegen mag, dass natürlich der erste Schwung verkauft und durchgearbeitet ist.
Das Problem mit den Einfügungen zerbricht mir auch den Kopf. Auf der Seite hebe ich es ja hervor:
http://www.cocoading.de/Tutorials/Besseres_KVO_2.html
So geht es nicht im Buch. Bliebe die Möglichkeit der Fettschrift, was aber wohl die "Einrückungen" zerstört. Unschön. Schließlich könnte man noch mit Zeilennummern arbeiten. Da denke ich nur, dass die zu schnell im Buch und beim Leser auseinander laufen. Ich hatte dieserhalb schon einmal im Forum angefragt, ob Kommentare abgetippt werden: "Nö, wenn dann die eigenen." Geht also nicht.
Das hätte ich aber auch gerne anders und wird sicherlich einen Mailverkehr mit der Layouterin wert sein. Ebenso der Umbruch des Source-Codes. Schrecklich. Insgesamt muss die Schrift kleiner (enger) werden und fest umgebrochen werden. Bei der Geschwätzigkeit von Cocoa ist dssa aber gar nicht einfach.
Meine Seite wird gerade umgebaut, was auch mit der Suchfunktion zusammen hängt. Da wird aber noch mehr gehen. Das verrate ich aber noch nicht.
Die Möglichkeit einen Bug zu melden, gibt es bereits!?
Im Vorwort findet sich ein Link zum Entwickler-Forum. Dort gibt es ein eigens eingerichtetes Forum und auch den Hinweis auf cocoading.de. Ich kann da kein Problem erkennen.
Nach Kapiteln ist ja wie nach Seiten. Nur: Glaube mir, es funktioniert nicht. Ich habe da meine Erfahrungen. Und frage mich *bitte* nicht, warum. Ich weiß nur, dass ich Fehler gemailt bekommen habe, die auf der Seite noch fehlten ... Dort aber gelistet waren. Ich dachte mir dann, dass es vielleicht zu unübersichtlich ist und da die meisten Mails ohnehin Kompilierungsfehler betrafen, habe ich daraus eine Kategorie gemacht. Es sind jetzt auch weniger Mails geworden, was aber natürlich auch daran liegen mag, dass natürlich der erste Schwung verkauft und durchgearbeitet ist.
Das Problem mit den Einfügungen zerbricht mir auch den Kopf. Auf der Seite hebe ich es ja hervor:
http://www.cocoading.de/Tutorials/Besseres_KVO_2.html
So geht es nicht im Buch. Bliebe die Möglichkeit der Fettschrift, was aber wohl die "Einrückungen" zerstört. Unschön. Schließlich könnte man noch mit Zeilennummern arbeiten. Da denke ich nur, dass die zu schnell im Buch und beim Leser auseinander laufen. Ich hatte dieserhalb schon einmal im Forum angefragt, ob Kommentare abgetippt werden: "Nö, wenn dann die eigenen." Geht also nicht.
Das hätte ich aber auch gerne anders und wird sicherlich einen Mailverkehr mit der Layouterin wert sein. Ebenso der Umbruch des Source-Codes. Schrecklich. Insgesamt muss die Schrift kleiner (enger) werden und fest umgebrochen werden. Bei der Geschwätzigkeit von Cocoa ist dssa aber gar nicht einfach.
Meine Seite wird gerade umgebaut, was auch mit der Suchfunktion zusammen hängt. Da wird aber noch mehr gehen. Das verrate ich aber noch nicht.
Die Möglichkeit einen Bug zu melden, gibt es bereits!?
Peter Maurer
Pommerscher Krummstiel
- Registriert
- 16.03.04
- Beiträge
- 3.077
Warum? Ihr macht das wohl ueber Leerstellen, denn mit Tabulatoren waer's ja gar kein Problem; aber sind die fetten Leerstellen wirklich breiter als die normalen?
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.
) 2003-2024 Apfeltalk | Made on a Mac