Newsgroup: it.comp.macintosh
Titolo: imparare Objc+Cocoa

il mondo della programmazione mi ha sempre affascinato e ho un paio di
ideuzze che vorrei sviluppare magari facendo anche qualche spicciolo.
ora io vengo da php e vorrei creare delle vere app per osx. come mi
muovo? dove trovo una bella guida cocoa+objective c (magari aggiornata a
xcode 3.0) ?

 wrote:

Non e' aggiornatissimo, ma un buono spunto per cominciare e':
http://www.macocoa.omitech.it/
Ciao
-- 
Riccardo Campana
pabel...@gmail.com
"Physics is like sex: sure, it may give some practical
results, but that's not why we do it"  (Richard Feynman)

 Ciao
grazie mi tuffo alla lettura

 wrote:

Lascia perdere Objective C e utilizza Python o Ruby.
E' molto piů comodo e semplice, oltre che puoi usarli anche per (quasi)
tutto il resto (compresa la programmazione web).
A me piace piů Python, per inciso.
-- 
cc = callcc {|cc| cc.call cc}; cc.call cc

 molto più comodo e semplice
In effetti se vuole usare Cocoa è meglio iniziare con ObjC, altrimenti
certe idiosincrasie non vengono comprese. (Per non parlare del debug.)
 - ∞

 certe idiosincrasie non vengono comprese. (Per non parlare del debug.)
Non sono d'accordo. ObjC è un linguaggio *notevolmente* più complesso da
maneggiare sia di Ruby che di Python. 
Quando incontra un'idiosincrasia, chiederà. Altrimenti gli facciamo solo
fare un lavoraccio per poco o nulla.


 maneggiare sia di Ruby che di Python. 
mmm python sembra carino (semplice) come sintassi ma mi permetterà (in
effetti è una domanda da 1 milione di dollari) di sviluppare su iphone?
il mio obbiettivo e realizzare qualche concept su quella macchina

 il mio obbiettivo e realizzare qualche concept su quella macchina
Allora ti vedo confuso: Objective-C e Cocoa *non* ti serviranno per
sviluppare sull'iPhone. Li si usa principalmente Javascript + xhtml +
css.


 wrote:

Certo, nel momento in cui PyObjC viene portato là su. Credo proprio che
libffi sia già operante su ARM, per cui...
 - ∞

 css.
Senza poter sapere nulla di ufficiale, ObjC e Cocoa saranno
probabilmente usati nell'SDK di febbraio prossimo, poiché già vengono
usati per scrivere il software che Apple usa sull'iPhone.
 - ∞

 usati per scrivere il software che Apple usa sull'iPhone.
"Esattevolmente" questo :)

 libffi sia già operante su ARM, per cui...
 oggi ho scoperto l'esistenza di sto PyObjC e sembra interessante!
intanto mi faccio amico cocoa!

 usati per scrivere il software che Apple usa sull'iPhone.
E a questo punto bisogna vedere perchè Python e Ruby non dovrebbero
essere supportati, visto che la tecnologia c'è già tutta ed è
distribuita con Leopard.


 distribuita con Leopard.
Il ponte Ruby è molto tradizionale, mentre quello Python usa libffi che
è un pezzo di codice assai arcano e bizzarro (ma immagino che un port
ARM esista...).
 - ∞

 ARM esista...).
Definire libffi arcano e bizzaro è a sua volta arcano e bizzarro. Per
dire ormai è mantenuto nel trunk del gcc. 
Tra l'altro faccio notare che libffi è usato pure da RubyCocoa, a quanto
avevo letto. Per dire su wikipedia, dice ancora così.


 avevo letto. Per dire su wikipedia, dice ancora così.
Infatti mi chiedevo come facessero a fare gli eventuali puntatori alle
closure, dopo aver scritto il post di cui sopra :D
 - ∞

 [...] A me piace piů Python, per inciso.
E se si volesse iniziare con Python? Puoi consigliare un qualche
sito/manuale online?
grazie. :)
   gia.




 "arcano e bizzarro". :)
Per me è completamente normale. Sono un bel po' di anni che lavoro con
linguaggi dinamici e costruire funzioni e classi al volo non è nulla di
strano, anche se i linguaggi statici cercano di farcelo credere. 
Ma anche nei linguaggi funzionali, che pure ho adoperato non poco, la
pratica è comune. Sostituendo funzione con predicato, si fa pure nei
linguaggi logici (anche li ho un po' di esperienza).
Certo, nel mondo statico è una cosa 'strana', principalmente perchè è
relativamente complessa da fare. E poi fin li... pensa, tempo fa ricordo
un casino poichè una data versione della glibc veniva fermata dai
sistemi di protezione di open bsd. 
Sostanzialmente il punto è che loro creavano un po' di codice eseguibile
nella sezione .data e poi ci saltavano dentro all'occorrenza: questo non
è forse generare una 'funzione' al volo? :)


 Grazie mille. Post bloccato. :)
come si fa?

 linguaggi statici cercano di farcelo credere. 
Che vuol dire costruirli al volo ?

 sistemi di protezione di open bsd. 
L'arcano non sta nel costruire funzioni al volo (senza scavare nei
linguaggi "belli", anche solo considerando JavaScript, quante chiusure
ho scritto), ma nel costruire funzioni *native* al volo, il che richiede
il port di libffi per adattarsi all'ABI di ciascuna architettura. Non è
affatto strano, ma è una cosa che i programmi statici di solito non
fanno.
 - ∞



L'esempio canonico, in JavaScript:
function creaSommatore(x) {
        return function(y) { return x + y; }
}
var somma2 = creaSommatore(2);
var somma4 = creaSommatore(4);
alert(somma2(5)); // mostra '7'
alert(somma4(5)); // mostra '9'
 - ∞

 fanno.
Come ti dicevo... lo faceva perfino la libc! :)
Diciamo che sono cose che non vengono troppo sbandierate in genere. 


 Che vuol dire costruirli al volo ?
Quando programmi in aereo con il macbook air.


 fretta. :-)
Infatti. Se poi uno si stanca, ci sono gli altri. Ma è molto più
frustrante, IMHO, partire da uno tosto e fare una fatica dell'accidenti.
L'importante con Python è poi programmare, programmare e programmare.
Solo leggendo, si impara poco. E leggere la documentazione dei moduli
che 9/10 fanno già quello che vuoi.


 alert(somma4(5)); // mostra '9'
Capito, a function is worth a thousand words.
Ne ho un'idea perché pratico un po' lua dove le funzioni sono uno dei 7 
o 8 tipi base, ma di fatto non programmo attivamente quindi non ero 
sicuro di cosa intendeste. 
Mi manca il gergo insomma anche detto "la problematica gergale" in 
ambito tecnico.
Python non li chiama "first class citizen" o qualcosa del genere ?

 Python non li chiama "first class citizen" o qualcosa del genere ?
si e no. in generale si dice che qualcosa in un linguaggio è un 'first
class citizen' per dire che lo si può manipolare agevolmente come i vari
componenti naturali del linguaggio.
In Python è facile manipolare gli oggetti. Le classi sono oggetti e le
funzioni pure sono oggetti. Da cui sono 'first class citizens'.


 funzioni pure sono oggetti.
Ossignur, ecco perché non sarò mai programmatore...
-- 
Per contattarmi:
http://formmailto.com/saltydog

 Ossignur, ecco perché non sarò mai programmatore...
Ma guarda che è una semplificazione, invece di avere entità separate le 
fai convergere.
In iolanguage mi sembra che anche non ci siano neanche parole chiave del 
linguaggio ma che siano anche queste oggetti.

 linguaggio ma che siano anche queste oggetti.
In Io ci sono un paio di parole chiave (method e block), ma come in
Smalltalk tutti i costrutti di controllo (if, while, for) sono metodi.
 - ∞

 Ossignur, ecco perché non sarò mai programmatore...
Perchè? E' una cosa semplice. E' una semplificazione e basta. Sai
maneggiare gli oggetti? Si: bene, allora puoi manipolare il tutto.
Nota che non è nemmeno una cosa che *devi* sapere. E' solo una comodità.
In altri linguaggi dove questa proprietà non è vera, per fare le stesse
cose ci vanno paginate di codice, il che rende tutto più complesso e
scomodo. E  purtroppo ci sono determinati problemi che si risolvono o
così oppure dannandosi il fegato (o ancora rinunciando).


 Diciamo che sono cose che non vengono troppo sbandierate in genere. 
Mi hai fatto ricordare che persino GCC genera codice che genera codice
in taluni casi. (Esempio:
void funzioneAltrui(int (*funzione)());
void a() {
        int x = 0;
        // funzione interna
        int b() {
                return x + 1;
        }
        // ...
        funzioneAltrui(&b);
        // ...
}
In questo caso gcc crea codice che crea un trampolino a runtime per
chiamare b passandogli anche un puntatore a x, mantenendo però int ...()
come signature. Da quando c'è il bit NX, però, non si può più usare...)
 - ∞

 Smalltalk tutti i costrutti di controllo (if, while, for) sono metodi
Questo ha un senso. Ma che siano oggetti... e pure le classi... boh.


 Questo ha un senso. Ma che siano oggetti... e pure le classi... boh.
E perchč? Se č possibile ricondursi ad un unico principio senza nessuna
complicazione aggiuntiva per nessuno, perchč non farlo?


 perchè non farlo?
Perché la mia mente semplice tra classi e oggetti così va in loop.


 Perché la mia mente semplice tra classi e oggetti cosě va in loop.
Puoi dimenticare la nozione e per te non cambierŕ nulla.
Ad ogni modo č un vero peccato: non c'č ragione per il problema di
esistere. Se poi ti parlassi della distinzione *logica* fra tipo e
classe (distinzione che molti linguaggi rispettano, per inciso)
collassi.


 Ad ogni modo è un vero peccato
Secondo me dovreste riformare (e uniformare) la terminologia alla luce
delle nuove possibilità. Intendo un glossario generale e univoco per
tutti i linguaggi.


 come signature. Da quando c'è il bit NX, però, non si può più usare...)
Non è vero. In primo luogo il 'bit nx' è una novità solo su X86. PPC,
SPARC e compagni hanno aggeggi simili da tempo.
Comunque se guardi, non è come dici tu. Ovvero il codice non è generato
a runtime, a quanto vedo. Semplicemente siccome C è tutto statico
l'implementazione tipica non ha bisogno di generare codice a runtime:
basta passare qualcosa che può essere utilizzato per raggiungere
l'ambiente della funzione chiamante.


 l'ambiente della funzione chiamante.
... perché la cosa che ti ho scritto sopra viene compilata in questo
modo:
void funzioneAltrui(int (*funzione)());
void a() {
        int x = 0;
        const void* puntatoreAdX = &x;
        // funzione interna -- come la compila GCC
        int b(void* puntatoreAdX) {
                return (*puntatoreAdX) + 1;
        }
        // ...
        void* spazioPerLaFunzione = alloca(...);
        // QUI! GCC inserisce del
        // codice che genera codice -- scrive in spazioPerLaFunzione
        // una funzione che richiama b(puntatoreAdX) ma che
        // non prende parametri, così da avere signature int ...();
        // Va generato qui perché a runtime non sappiamo x, usato da b,
        // dove verrà allocato.
        // NB in questo modo, se ad esempio funzioneAltrui() richiamasse
        // a() ancora, la seconda chiamata a funzioneAltrui() avrà
        // un "b" differente -- quello che punta alla seconda istanza di
        // x, prensente nello stack della seconda chiamata di a().
        funzioneAltrui( (int (*)())
                spazioPerLaFunzione);
        // ...
}
 - ∞

 a runtime
a compile time.
 - ∞

 tutti i linguaggi.
Sarebbe sensato. In effetti la terminologia ci sarebbe, ma molti
linguaggi mainstream fanno fare casino.
