- Netzach
- Medlem ●
- Stockholm
Har erfarenhet av Java och grundläggande objektorienterad PHP, nu vill jag lära mig Objective C.
Problemet är att jag nästan blir deprimerad och känner mig uppgiven när jag ser den kaotiska kod som finns i tom de enklare tutorialarna, varför finns ens h-filen? Den verkar ju knappast fylla någon annan funktion än att förvirra den ovane cocoa-pillaren (läs mig).
För mig är tutorials med mycket förklarande text kontraproduktivt, kort och koncist är grejen för mig. Minns när jag skulle lära mig PHP, vilket jag gjorde helt via Google, så att säga, då utgick jag ifrån vad saker hette i Java och försökte hitta exempel på när motsvarande funktioner i PHP användes, kom några tillfällen på mig själv att ha hittat vad jag sökte på sidor där jag inte ens kunde språket på.
Så, kort och gott, finns det någon tutorial där ute som riktar sig till folk som vill börja med "Textmate och Terminal", för att bli bekväm med språket innan man ger sig på monstret till XCode? CLI duger gott till att lära sig grunderna, där GUI bara är ett hinder.
imo:
alt1. köp "Programming in Objective-C" av Stephen Kochan.
alt2. träna in lite 'vanlig' c, köp sedan "Objective-C Pocket Reference" av Andrew Duncan.
båda böckerna är ganska billiga (om jag minns rätt, iaf den senare) och läsvärda.
alt2 kanske passar bättre om man 'kan' programmera sedan gammalt.
Det finns en bok som heter "Beginning Mac OS X Programming" som steg för steg tar dig igenom hela bakgrunden, från utvecklingsmiljön, grunderna i C (som du måste kunna innan du kan gå över till Objective C) och Objective C.
Jag tycker nog att du ska omvärdera tanken på att lära dig C genom terminal. Xcode är inte svårt och i t.ex. den boken jag nämnde beskrivs precis vad du behöver veta, och därefter är det ett bra hjälpmedel.
Hmm, men allt som skapas när startar ett nytt project i XCode käns lite väl rörigt när man skall börja lära sig det. Det fanns ju en anledning till att läraren, när jag lärde mig Java här om året, avrådde en att sitta i Eclipse eller liknande när man skulle lära sig språket.
Usch, känner mig som ett tjurigt barn.
Men men, det verkar ju inte vara bättre än att det är en rejäl ingångströskel för Objective C om man jämför med Java och objektorienterad PHP, så det kanske bara är att bita i det sura äpplet och känna sig "Hello World"-inkompetent tills dess att bitarna faller på plats? I sådant fall väntar jag in Leopard så att jag iaf kan använda mig av en automatisk Garbage Collector. Minns hur illa det var att sitta och göra sådant manuellt i Pascal.
Edit:
Hmm, denna tutorial verkar kanske vara någonting för mig, dvs börjar i C och hamnar slutligen i XCode:
http://www.zathras.de/angelweb/masters-of-the-void.htm
Men men, det verkar ju inte vara bättre än att det är en rejäl ingångströskel för Objective C om man jämför med Java och objektorienterad PHP, så det kanske bara är att bita i det sura äpplet och känna sig "Hello World"-inkompetent tills dess att bitarna faller på plats?
Vill du ha ett Hello World-program finns det ett på svenska Wikipedias artikel om Objective-C. Engelska hade också en del exempel, men inget som visade allt i ett stycke.
Vill du ha ett Hello World-program finns det ett på svenska Wikipedias artikel om Objective-C. Engelska hade också en del exempel, men inget som visade allt i ett stycke.
Att jag missat att kolla där är rent ut sagt pinsamt. :">
.h-filen kan man ha åsikter om... Men att de skulle göra Objectiv-C speciellt svårt tycker jag inte.
Det känns som att man skriver klassen på två olika ställen på samma gång, vilket känns som dubbelarbete när man är van vid Java. Såg en referens till interfacen i h-filerna som en sort innehållsförteckning, men det känns ju heller inte lika smidigt som javadoc.
Tror nog det är ett klassiskt "Så här skall det vara, för så är jag van vi det!" från min sida.
Alla språk kan ju inte vara bra på allt, de har ju sina egna för- och nackdelar. Objective C får ju äntligen sin garbage collector nu med Leopard, vilket är trevligt.
Det känns som att man skriver klassen på två olika ställen på samma gång, vilket känns som dubbelarbete när man är van vid Java. Såg en referens till interfacen i h-filerna som en sort innehållsförteckning, men det känns ju heller inte lika smidigt som javadoc.
Det är nog ingen som tycker det är direkt smidigt... snarare var det väl ett nödvändigt ont förr i tiden. Det finns väl knappt några modernt uppfunna språk som håller på med sånt heller.
Det är nog ingen som tycker det är direkt smidigt... snarare var det väl ett nödvändigt ont förr i tiden. Det finns väl knappt några modernt uppfunna språk som håller på med sånt heller.
Enligt Wikipedia så kan man ha dem i samma fil, fungerade i deras Hello World iaf, vilket kan vara skönt iaf den första biten i att lära sig syntaxen.
Sen är väl header-filen avsedd för att kompilatorn skall veta att funktionen/metoden/klassen m.m. man hänvisar till existerar.
Hmm. Innan jag jag fyllde in min egna printf()-funktion i interfacet så hittade den funktionen iaf, så det kanske är mer legacy än viktigt.
Hmm. Innan jag jag fyllde in min egna printf()-funktion i interfacet så hittade den funktionen iaf, så det kanske är mer legacy än viktigt.
Fast då fanns de väl i samma fil ? Header filerna är när man har koden uppdelad i flera filer. fil1.m har ingen koll på vad som finns i fil2.m om man inte inkluderar fil2.h.
Fast då fanns de väl i samma fil ? Header filerna är när man har koden uppdelad i flera filer. fil1.m har ingen koll på vad som finns i fil2.m om man inte inkluderar fil2.h.
Jupp.
Hmmm. Så header-filen är egentligen bara till för andra klasser? Varför kunde den inte ha tittat i m-filen vid kompilering? Det är ju praktiskt taget likadant formulerat, med den skillnad att m-filen innehåller den faktiska koden. Känns som gjort för slarvfel.
Jag är inte insatt i kompilatorutveckling och vad det finns för för- och nackdelar, men man kan ju konstatera att det just så många moderna (gillar inte ordet, hitta ett bättre!) kompilatorer gör. Gissningsvis för att det är mycket bekvämare.
Å andra sidan kan man åstadkomma samma sak genom att skriva tomma metoder i den riktiga filen. Vilket då råkar se ut nästan som en headerfil.
Det "headerlösa" kompilatorer gör är att vid kompilering stoppa med lite metadata som beskriver metodersignaturer mm. Denna läses sedan automatiskt när man skapar en referens till den kompilerade filen.
Tjaaa, gcc gav mig kompileringsfel när jag hade metoder deklarerade i headern som inte fanns i min m-fil.
Det var för ett par minuter sedan, så det kanske bara var varningar, men det var metoder jag ändå hade tagit bort så det spelade ingen roll.
Tjaaa, gcc gav mig kompileringsfel när jag hade metoder deklarerade i headern som inte fanns i min m-fil.
Det var för ett par minuter sedan, så det kanske bara var varningar, men det var metoder jag ändå hade tagit bort så det spelade ingen roll.
Menar du verkligen kompileringsfel och inte länkningsfel?
Menar du verkligen kompileringsfel och inte länkningsfel?
Vet faktiskt inte, mycket möjligt, när jag väl skrev in posten ovan så hade det gått ett par minuter, och iom att det var metoder/funktioner som jag hade plockat bort så brydde jag mig inte om innehållet i felmeddelandet.
Vet faktiskt inte, mycket möjligt, när jag väl skrev in posten ovan så hade det gått ett par minuter, och iom att det var metoder/funktioner som jag hade plockat bort så brydde jag mig inte om innehållet i felmeddelandet.
Ja, hursomhelst fungerar kompilering om du bara har h-filer utan implementation eller objektfiler nånstans. Länkning kräver att du har objektfiler eller kan kompilera ihop dem från implementationsfil(er).