Also was ein Pointer ist sollte man schon wissen. Sonst stehst Du spätestens bei den etwas "extravaganteren" Sachen auch bei Cocoa auf dem Schlauch.
Nimm Kram wie
- (BOOL)fileExistsAtPath:(NSString *)path isDirectory:(BOOL *)isDirectory
oder denk an CBV/CBR. Wenn Du bei letzterem den Unterschied nicht kennst kannst Du Dir 'nen Wolf debuggen und weißt immer noch nicht was da schiefläuft.

Natürlich ist das "angenehm" wenn man sich da keine Gedanken drum machen muß -- ich komme auch aus der Java-Ecke und habe mich erst damit beschäftigen müssen.
Aber letztendlich lohnt es sich; Du kannst damit halt nette Sachen machen, die ohne definitiv schwieriger bis unmöglich wären.

Wir sprachen von einem Anfänger.

Original von seb2
Also was ein Pointer ist sollte man schon wissen. Sonst stehst Du spätestens bei den etwas "extravaganteren" Sachen auch bei Cocoa auf dem Schlauch.
Nimm Kram wie
- (BOOL)fileExistsAtPath:(NSString *)path isDirectory:(BOOL *)isDirectory

Aber das klappt doch immernoch, wenn er diese ID-Idee hat.

Original von pseuss
ja von squeak habe ich schon was gehört und ich hatte es als ich meine windose noch hatte auch drauf nur ich habe null gechekt was man da machen kann und machen muss. Mich haben diese blöden Augen generft die da immer der Maus folegn und für mich was das einfach kinderkack. Naja ich werde mir es dann nochmal anschauen.
Gruß pseuss

Die Augen gehören zu der Katze, sie ist das Logo von Squeak, nicht
verwechseln mit der Logo Steuerung von Siemens oder der Programmiersprache Logo und wenn eine Katze eine Maus fängt gibt es logischerweise ein Squeak.
Das es Kinderkack und nur Frauensache ist halte ich für ein Vorurteil es ist eine
Programmiersprache und zwar Smalltalk. Die Programmiersprache von Cocoa ist
zwar nicht Smalltalk sondern Objetive-C die wiederum eine Hybridsprache ist also
eine Zusammensetzung von C und Smalltalk, aber leider gibt es für Anfänger im
Netz keine Literatur auf Deutsch zu Objetiv-C ohne vorkenntnisse zu haben, weshalb ich dir zunächst mal Squeak empfohlen habe.


Viel spaß!

cu
Josef

Ok. nicht ganz eventuell Cocoa Workshop von Peter Wollschläger.

oder:

PFA Lektion1: Unser erstes Projekt von Tom9811

oder:

Einstieg in Objective C von versch. Authoren u.a , Tom9811 , Kay etc. ...

cu
Josef

Nun, ich bin größtenteils der Ansicht von Tom.

Das Einzige, was ich von meinen C-Kenntnissen bis dato wirklich gebraucht habe, sind Schleifen und IF-Abfragen.

Nur bekomme ich noch immer nichts gebacken, weil sich mir die Grundidee hinter Cocoa noch so ein bisschen verschließt.
Die Grundidee hinter Cocoa im Speziellen und der objektorientierten Programmierung im Allgemeinen.

Tobi_M schrob:
Oder was ist der Unterschied zwischen if (x = 1) und if (x == 1)?

Ersteres ist ein Schreibfehler, der einem viele schlaflose Nächte bereiten kann.
Man rechnet einfach nicht mit ihm.
Deshalb ist die Schreibweise angenehmer.
Sollte man da versehentlichschreiben, meckert der Compiler rum

[Jaja, ich weiß: Ersteres ist eine Zuweisung, die bei Erfolg ein 'true' an die Abfrage zurückgibt, i.d.R. immer erfolgreich verläuft und deshalb immer zutrifft; letzteres ein Vergleich, der ein 'true' zurückgibt, wenn Wert und Variable den identischen Wert haben, ansonsten ein 'false' meldet.
Und was ist mit if(1 === x)? +scnr+]

Man, man, man, das müsste ich mal alles überarbeiten ...

BTW: Es gibt tatsächlich sinnvolle Anwendungsgebiete für Zuweisungen in "Parametern". Klassiker ist die Traversierung: Wie man sieht, ist in der Schleife doppelt geklammert. Macht man das nicht, so meckert nämlich der Compiler. Und da man sinnvollerweise nur mit dden Schaltern -Wall und -Werror compiliert, würde das Programm nicht übersetzt. Mit den doppelten Klammern sagt man aber dem Compiler: "Jung, isch weiß, wat isch dunn! Haalt dä Fress!"

Ja, ihr habt schon recht, dass man nicht unbedingt C können muss. Man kann natürlich auch mit Objective-C anfangen. In Objective-C-Büchern sind ja die C-Grundlagen auch drin.
Ich denke aber, dass es besser ist, zuerst ohne Objekte und anderem komplizierten Zeugs ein bißchen zu programmieren.
Einfache kleine Programme zum Lernen von if, while, for, Funktionen, Datentypen usw. sind wirklich sehr hilfreich! Das sind halt die Grundlagen für alles weitere.

Tobi

Das ist ein Punkt: C ist einfacher als Objective-C, weil OOP nun einmal abstrakte Konzepte einführt. Deshalb kann man das auch so machen, dass man "C-Primitive" einbettet. Ob das davor, dabei oder wie auch immer geschieht – Ich bin da selbst zwiespältig.

Wenn man allerdings C lernt, lernt man mehr als das. Es gibt in jedem C-Buch dicke Kapitel über Pointer-Arithmetik und mehrfache Felder, Syntax-Wüsten mit * und [] usw. usf. Das ist ja meist das Schwierigste bei C – und bei Objective-C erst einmal nicht erforderlich.

Dann gibt es mehr oder weniger Ausführungen zu Konzepten von C. Diese hallte ich sogar für schädlich, wenn man eigentlich Objective-C lernt. Ich bin mir sicher, dass ich OOP leichter gelernt hätte, wenn ich nicht vorher Assembler und C in meinem Kopp gehabt hätte.

hm weiß nicht ob mich c dabei gestört hat ...

ich kann relativ gut in Objekten denken und auch relativ gut prozedural denken ... (ich fühle mich wie einstein .. alles ist relativ...)

was mir immer wieder Probleme bereitet ist wie Lucas schon schrieb hinter die Konzepte der umgebenden API zu steigen wobei das relativ schnitte ist ob die Cocoa, STL oder exec heißt

allerdings sag ich auch das, wenn man im kopf hat das Cocoa Ereignisorientiert ist und der meiste C++ kram "herumkomandiert" werden muß geht das dann eigentlich relativ gut.

was ich aber aus eigner Erfahrung weiß ist das ich rettungslos aufgeschmissen wäre ohne meine Grundlagen:

das bedeutet auch in fremden sprachen zu erkennen halt mal da wird ne variable irgendwie geladen / übergeben das da kann nur eine datensatz sein .. und das komische da ist was völlig deformiertes.

ich hab meine Grundlagen aus Bausatz Rechnern und dem zusammenlöten aus TTL Elektronik entsprechenden Basic Dialekten etc pp und ich bin heilfroh das ich weiß wie fließkommaarithmetik funktioniert

ich denke ab und an vergessen die Profis das sie den ganzen Kram inclusive dem abstraktem Softwaredesign mal alles gelernt haben und sich nun "nur mal schnell" in eine neue API einarbeiten müssen.

und nein ich denke bei Grundlagen nicht wirklich an Pointerarithmetik aber ich denke er sollte wissen was es ist dieser >Pointer<

er muß sich sicher nicht per Pointer durch wilde structs hangeln - aber vllt wissen das man von variablen ihren Inhalt und eben auch ihre Adresse erhalten kann und wie man damit umgeht und vor allem Wieso das ganze funktioniert

weil dann wird dann auch klar was ein dangling Pointer ist und warum man dieses komische retain an manche Sachen schicken soll ...

ym2c so ich geh weiter meinen View vergewaltigen ... hat jemand eine schöne Routine zur Analyse eines Baumes? ich brauch grad eine ^^;

Möge das Spice von Arrakis mit euch sein.
Ich werde mich 1 Woche mit squeak beschäftigen, da stinkt und qualmt wenigstens
nichts.

cu
Josef

Original von Tom9811
BTW: Es gibt tatsächlich sinnvolle Anwendungsgebiete für Zuweisungen in "Parametern". Klassiker ist die Traversierung:

Ick weeß
Solange Zuweisung Dingens zu nextObject von eneMeneMuh klappt... +möp+
Wenn nextObject nicht existiert gibt es ein FALSE und die Schleife bricht ab.
Deshalb ja auch 'i.d.R.' +g+
ein
ist da allerdings eher kontraproduktiv.
Weshalb ich mir das 1 == x angewöhnt habe.
In der WHILE sehe ich dann, obs hakt oder nicht - und zwar schon daran, wie ich es geschrieben habe.

Original von Tom9811
Mit den doppelten Klammern sagt man aber dem Compiler: "Jung, isch weiß, wat isch dunn! Haalt dä Fress!"

Det war mir neu

Tobi_M:
Ich hab mehrere Jahre mit PHP absolut unobjektorientiert rumprogrammiert.
(Ick weeß: PHP != Programmieren +g+)
Dann irgendwann haben die da ooch mit Klassen und Instanzen anjefangen.
Es ist aber halt n Unterschied, ob man
$instanz->funktion('arg1', 'arg2', 'arg3');
oder
[instanz erstesArgument:@"arg1" zweitesArgument:@"arg2" drittesArgument:@"arg3"];
aufrufen muss.
Schon allein des Aufbaus der Methoden wegen.
Insofern sind Pointer, Variablen, Arrays, int, bool und Gezeugs keine großartigen Fremdwörter für mich.

Aber:
ich bin beispielsweise gewöhnt, den Inhalt eines Arrays mit sizeof($array) zu erfragen.
Wie komm ich jetzt darauf, dass es [anArray count]; heißt?
Aus einer sprachenweiten Funktion wird plötzlich eine objekteigene Methode...
Und das sind nur Kleinigkeiten...
Ein nächstes Problem sehe ich beispielsweise in mehrdimensionalen Arrays.
In PHP ist es einfach $array[0][0] für das erste Element des ersten Objektes im Array.
Und in Cocoa? Gut, mittlerweile weiß ich dank Toms Hilfe, dass ich das erste Objekt mittels [anArray getObjectAtIndex:0]; bekomme.
Und dann?
Dieses als neues Array-Objekt initiieren um dann mittels [anNewArray getObjectAtIndex:0]; auf das erste Element zuzugreifen?
Falls ja wäre das kontraproduktiv und suboptimal. Insofern denke ich mal, dass es auch anders gehen muss ; )

Fakt ist: Schleifen, und das Zeugs hilft mir weiter.
Aber wie steht es mit 'switch'-Anweisungen? Gibts die auch in Obj-C?
Wenn ja: wie rufe ich die da auf?
In PHP siehts so aus: (Scheiß auf Typendeklarationen :D)


Und in Obj-C?


Oder wie oder was oder wem?

Das übliche bool var = (var2 == true ? false : true; funktioniert ja auch...
Und wie steht es mit var = !var; ?

Vereinfacht vieles, wird aber nur in wenigen sehr speziellen Büchern angesprochen.
Ist also nicht überlebensnotwendig.

Diese ganzen Dinge sind jetzt aber nicht sooo kompliziert, dass sie unbedingt in mehrmonatiger Anwendung verinnerlicht werden müssen. (okay. Pointer sind schon etwas schwieriger zu begreifen)

chartus:
Ich habe noch dieses prozedurale Fließgescripte im Schädel und werde es einfach nicht los. Mir fehlt einfach die Abstraktion der OOP.

Original von Lucas de Vil
chartus:
Ich habe noch dieses prozedurale Fließgescripte im Schädel und werde es einfach nicht los. Mir fehlt einfach die Abstraktion der OOP.

hm was mir persönlich geholfen hat:

prozuderal ist meist: "gib mir das!" "tu das!" "mach jenes!"

Cocoa ist dagegen: "kannst du mir das geben?" "ist das fertig?" "sag mir bescheid wenn das passiert"

vor allem die letzte Formel ist ein guter schlüssel

nicht andere Klassen herumkommandieren sondern einfach delegates observer etc setzen und auf Informationen warten.

damit erschlägst du schonmal Cocoa und wenn du dir dann in deinen eigenen Klassen und Modellen angewöhnst notifications und delegates zu verwenden hast du IMHO gewonnen

sozusagen ist eine delegate einfach nur die nette anfrage an eine klasse das du dich für bestimmte sachen iintressierst und informiert werden möchtest oder zum ablauf gefragt werden möchtest.

du trägst bei einem tableview zb dich als delegate ein - was passiert? der tableview fragt dich bei jeder seiner aktionen ob du auch was dazu zu sagen hast. du must dem tableview nicht sagen er soll! sondern der tablewiev fragt im richtigen moment ob du möchtest ^^;;

oO(man bin ich schön abstrakt ^^;)

Original von Lucas de Vil

Original von Tom9811
Ein nächstes Problem sehe ich beispielsweise in mehrdimensionalen Arrays.
In PHP ist es einfach $array[0][0] für das erste Element des ersten Objektes im Array.
Und in Cocoa? Gut, mittlerweile weiß ich dank Toms Hilfe, dass ich das erste Objekt mittels [anArray getObjectAtIndex:0]; bekomme.
Und dann?
Dieses als neues Array-Objekt initiieren um dann mittels [anNewArray getObjectAtIndex:0]; auf das erste Element zuzugreifen?
Falls ja wäre das kontraproduktiv und suboptimal. Insofern denke ich mal, dass es auch anders gehen muss ; )

Könntest dir doch ne Klasse für zweidimensionale Arrays schreiben und da dann voll rumoptimieren…

Original von chartus
prozuderal ist meist: "gib mir das!" "tu das!" "mach jenes!"

Cocoa ist dagegen: "kannst du mir das geben?" "ist das fertig?" "sag mir bescheid wenn das passiert"

Ich würde das anders Forumlieren:

Prozedural: du Funktion, nimm diese Daten und Parameter, verarbeite sie und gib mir die bearbeiteten Daten als Ergebnis zurück.

Objektorientiert: du Objekt, du musst dich jetzt in bestimmter Weise verändern. Benutze dazu die Parameter hier.

Michael

Ich ebenso.

Prozedural
x -> func -> y

OOP:
// wildes Netz von Verbindungen mit Nachrichten

Original von Michael
Ich würde das anders Forumlieren:

Prozedural: du Funktion, nimm diese Daten und Parameter, verarbeite sie und gib mir die bearbeiteten Daten als Ergebnis zurück.

Objektorientiert: du Objekt, du musst dich jetzt in bestimmter Weise verändern. Benutze dazu die Parameter hier.

Michael

technisch ist das auf jeden fall sauberer - allerdings war bei mir der Knackpunkt der Schritt zur Ereignis basierten Programmierung - darum meine Formulierung

wenn man es darauf anlegt kann man auch in einer Super Über Klasse alles prozuderal machen was irgendwie den Esel am schwanz aufzäumt

ich hab nun nicht Informatik studiert sondern bin Autodidakt und ich hab es immer so empfunden das die wichtigsten Sachen in der OOP Vererbung / Kappslung / und halt gute ereignisgesteuerte Programmierung ist

man schaue nur mal auf KVO oder verwandte Konzepte...

aber wie gesagt das war mein Knackpunkt an OOP ein anderer erlebt sein Schlüsselerlebnis vllt mit der Vererbung ^_-

Original von chartus

Cocoa ist dagegen: "kannst du mir das geben?" "ist das fertig?" "sag mir bescheid wenn das passiert"

Du meinst also, bevor ich ne Tabellenspalte das 'enabled' per 'setEnabled: NO' entziehe sollte ich erst einmal per 'isEnabled' schauen, ob das Ding überhaupt enabled ist?

chartus
du trägst bei einem tableview zb dich als delegate ein - was passiert? der tableview fragt dich bei jeder seiner aktionen ob du auch was dazu zu sagen hast. du must dem tableview nicht sagen er soll! sondern der tableview fragt im richtigen moment ob du möchtest

Beispielsweise: Wenn Cocoa merkt, dass ein Wert eingegeben wurde sagt es dem Delegate, dass ein Wert eingegeben wurde. Da es mein Delegate interessiert, macht es irgend einen Unsinn mit der Eingabe.
Wenn Cocoa merkt, dass die Spaltenanordnung vertauscht wurde sagt es dem Delegate, dass die Spaltenanordnung vertauscht wurde. Da es meinem Delegate völlig Banane ist, passiert nichts weiter.

Das ist doch schon mal sehr gut zu wissen

læng:
Klasse Idee!
Wie? +scnr+

Objekt, Subjekt... Alles suspekt

Original von Lucas de Vil
Du meinst also, bevor ich ne Tabellenspalte das 'enabled' per 'setEnabled: NO' entziehe sollte ich erst einmal per 'isEnabled' schauen, ob das Ding überhaupt enabled ist?

naja vllt nicht unbedingt jedesmal prüfen - aber

wenn du prozedural herangehst kannst du dich mehr oder weniger direkt darauf verlassen das dieses setEnabled:NO sofort und direkt wirkung zeigt.

so kann es aber bei einem Objekt sein das es zb deinen Wunsch erstmal cached bis zb andere sachen abgearbeitet sind (in der regel sowieso bis zum nächsten runloop) oder es kann zb folgendes passiern: du setzt enabled auf NO - das objekt schickt nun möglicherweise eine message an ein delegate um zu sagen "ich will mich jetzt disablen!" und es kann möglicherweise sein das das delgate es verbietet oder zusätzlich andere dinge auslöst etc.

objekte sind smart besitzen einen eigenen willen und wollen höflich behandelt werden ^^; c-funktionen kann man rumschubsen die sind eh doof *eg*