Objective-C: differenze tra le versioni

Versione delle 04:31, 29 giu 2024

Versione attuale delle 15:58, 25 mar 2025

(2 versioni intermedie di 2 utenti non mostrate)

Riga 212:

Le rappresentazioni interne di questi metodi possono variare con le diverse implementazioni di Objective C.

Se <code>myColor</code>, nell'esempio precedente, fosse della classe <code>Color</code>, internamente il metodo d'istanza <code>-changeColorWithRed:green:blue: </code> potrebbe essere etichettato <code>_i_Color_changeColorWithRed_green_blue</code>, dove </code>i</code> seguito dal nome della classe, si riferisce al fatto che è un metodo d'istanza ed i due punti (:) sono sostituiti dal [[trattino basso]] (_). Dato che l'ordine dei parametri fa parte del nome del metodo, esso non può essere cambiato.

In ogni caso i nomi interni delle funzioni sono usati raramente in maniera diretta e generalmente anche i messaggi inviati sono convertiti in funzioni definite in librerie di [[run-time]] e non accedono direttamente ai nomi interni. Ciò è dovuto anche al fatto che al momento della [[compilazione]] non sempre si conosce quale metodo sarà effettivamente chiamato, perché la classe del destinatario (l'oggetto a cui viene inviato il messaggio) potrebbe essere sconosciuta fino al run-time.

Riga 583:

L'implementazione dell'Objective C usa un semplice [[run-time system]] scritto in [[linguaggio C]] che aumenta di poco la dimensione delle applicazioni. Al contrario, la maggior parte dei sistemi object-oriented esistenti quando fu creato (e [[Java (linguaggio di programmazione)|Java]] tuttora) usava una grossa [[macchina virtuale]] invasiva per l'intero sistema. I programmi scritti in Objective C tendono ad essere di poco più grandi delle dimensioni del loro [[codice oggetto]] e delle [[libreria software|librerie]] usate (che generalmente non devono essere incluse nel codice distribuito), al contrario ad esempio dei sistemi [[Smalltalk]] dove grandi quantità di memoria sono necessarie semplicemente per aprire una [[finestra (informatica)|finestra]].

Il linguaggio può essere implementato con un compilatore C (in [[GNU Compiler Collection|GCC]], prima come un [[preprocessore]] ed in seguito come un modulo del compilatore) piuttosto che con un nuovo compilatore. Ciò consente all'Objective C di sfruttare l'enorme mole di codice, librerie e strumenti già esistenti in C che può essere adattata in Objective C per fornire un'interfaccia object-oriented. TutteTutti questi fattori riducono le barriere d'ingresso al nuovo linguaggio, fattore che costituì il problema principale di Smalltalk negli [[anni 1980|anni ottanta]].

Le prime versioni di Objective C non supportavano la [[garbage collection]]. Al tempo questa scelta fu oggetto di discussioni e in molti (ai tempi di Smalltalk) la consideravano un lungo "tempo morto" in cui il sistema era reso non più utilizzabile. Anche se qualche implementazione di terze parti (principalmente [[GNUstep]]) aveva già aggiunto questa caratteristica, è stata implementata da [[Apple]] una tecnica simile tramite [[Automatic Reference Counting|ARC]] in [[Mac OS X Leopard]], ma non è disponibile per applicazioni implementate per versioni precedenti del [[sistema operativo]].<ref>{{Cita web | url=https://www.apple.com/macosx/developertools/xcode.html | titolo=Mac OS X Leopard – Xcode 3.0 | autore=Apple, Inc. | anno=22 agosto 2006 | sito=apple.com | accesso=22 agosto 2006 | lingua=en | urlarchivio=https://web.archive.org/web/20071024144921/http://www.apple.com/macosx/developertools/xcode.html | dataarchivio=24 ottobre 2007 | urlmorto=sì }}</ref>

Un'altra critica comunemente fatta all'Objective C è quella di non avere un supporto nativo per i [[namespace]]. I programmatori sono perciò costretti ad aggiungere [[prefisso|prefissi]] in maniera più o meno arbitraria ai nomi delle classi che implementano, fatto che può causare collisioni. Dal [[2007]] tutte le classi e le funzioni di [[macOS]] in ambiente [[Cocoa (software)|Cocoa]] hanno il prefisso "NS" (es. ''NSObject'' o ''NSButton'') per identificarle chiaramente; "NS" deriva dal nome delle classi definite durante lo sviluppo di [[NeXTSTEP]].

Dato che Objective C è uno stretto [[superinsieme]] del C, non tratta i tipi primitivi del C come [[first-class object]].