Objective-C

Objective-C
Desarrollador(es)
?
Información general
Extensiones comunes	.h, .m, .mm, .M
Paradigma	orientado a objetos
Apareció en	1980
Diseñado por	Brad Cox y Tom Love
Última versión estable	2.0
Sistema de tipos	estático, dinámico, débil
Implementaciones	Clang, GCC
Dialectos	Objective-J, TOM
Influido por	C, Smalltalk
Ha influido a	Groovy, Java, Nu, Objective-C++, Swift,

Objective-C es un lenguaje de programación orientado a objetos creado como un superconjunto de C para que implementase un modelo de objetos parecido al de Smalltalk. Originalmente fue creado por Brad Cox y la corporación StepStone en 1980. En 1988 fue adoptado como lenguaje de programación de NEXTSTEP y en 1992 fue liberado bajo licencia GPL para el compilador GCC. Actualmente se usa como un lenguaje principal de programación para Mac OS X, iOS y GNUstep, además de Swift.

Historia

A principios de los 80, el software se desarrollaba usando programación estructurada. La programación estructurada se estableció para ayudar a dividir los programas en pequeñas partes, haciendo más fácil el desarrollo cuando la aplicación se volvía muy grande. Sin embargo, como los problemas seguían creciendo al pasar el tiempo, la programación estructurada se volvió compleja dado el desorden de algunos programadores para invocar instrucciones repetitivamente, llevando a código spaghetti y dificultando la reutilización de código.

Muchos vieron que la programación orientada a objetos sería la solución al problema. De hecho, Smalltalk ya tenía solucionados muchos de estos problemas: algunos de los sistemas más complejos en el mundo funcionaban gracias a Smalltalk. Pero Smalltalk usaba una máquina virtual, lo cual requería mucha memoria para esa época, y era demasiado lento.

Objective-C fue creado principalmente por Brad Cox y Tom Love a inicios de los 80 en su compañía Stepstone. Ambos fueron iniciados en Smalltalk mientras estaban en el Programming Technology Center de ITT en 1981. Cox se vio interesado en los problemas de reutilización en el desarrollo de software. Se dio cuenta de que un lenguaje como Smalltalk sería imprescindible en la construcción de entornos de desarrollo potentes para los desarrolladores en ITI Corporation. Cox empezó a modificar el compilador de C para agregar algunas de las capacidades de Smalltalk. Pronto tuvo una extensión para añadir la programación orientada a objetos a C la cual llamó «OOPC», Object-Oriented Programming in C. Love mientras tanto, fue contratado por Shlumberger Research en 1982 y tuvo la oportunidad de adquirir la primera copia de Smalltalk-80, lo que influyó en su estilo como programador.

Para demostrar que se hizo un progreso real, Cox mostró que para hacer componentes de software verdaderamente intercambiables solo se necesitaban unos pequeños cambios en las herramientas existentes. Específicamente, estas necesitaban soportar objetos de manera flexible, venir con un conjunto de bibliotecas que fueran utilizables, y permitir que el código —y cualquier recurso necesitado por el código— pudiera ser empaquetado en un formato multiplataforma.

Cox y Love luego fundaron una nueva empresa, Productivity Products International —PPI—, para comercializar su producto: un compilador de Objective-C con un conjunto de bibliotecas potentes.

En 1986, Cox publicó la principal descripción de Objective-C en su forma original en el libro Object-Oriented Programming, An Evolutionary Approach. Aunque él fue cuidadoso en resaltar que hay muchos problemas de reutilización que no dependen del lenguaje, Objective-C frecuentemente fue comparado detalladamente con otros lenguajes.

Popularización mediante NeXT

En 1988, NeXT licenció el Objective-C de StepStone, nuevo nombre de PPI, dueña de la marca Objective-C, y extendió el compilador GCC para dar soporte a Objective-C al mismo tiempo que desarrolló las librerías AppKit y Foundation Kit sobre las que se basaron la interfaz de usuario y la interfaz de creación de NeXTStep. Mientras que las estaciones de trabajo de NeXT no consiguieron hacer un gran impacto en el mercado, las herramientas fueron ampliamente alabadas en la industria. Esto llevó a NeXT a abandonar la producción de hardware y enfocarse en las herramientas de software, vendiendo NeXTstep —y OpenStep— como una plataforma para la programación a medida.

El trabajo para extender GCC fue liderado por Steve Naroff, que se unió a NeXT proveniente de StepStone. Los cambios del compilador fueron puestos a disposición bajo términos de licencia GPL, pero no las librerías de tiempo de ejecución, dejando la contribución de código abierto inutilizable para el público general. Esto llevó a que otras compañías desarrollaran esas librerías bajo licencias de código abierto. Más tarde, Steve Naroff fue también un colaborador principal al trabajo de Apple de construir la interfaz de Objective-C Clang.

El proyecto GNU comenzó a trabajar en su implementación de Cocoa como software libre, llamado GNUstep y basado en el estándar de OpenStep.​ Dennis Glatting escribió el primer sistema en tiempo de ejecución de GNU Objective-C en 1992. El sistema GNU Objective-C, que ha sido usado desde 1993, es uno de los desarrollados por Kresten Krab Thorup cuando era un estudiante universitario en Dinamarca. Thorup también trabajó en NeXT desde 1993 hasta 1997.

Desarrollo de Apple y Swift

Tras adquirir NeXT en 1996, Apple empleó OpenStep en su nuevo sistema operativo, Mac OS X. Este incluía Objective-C y la herramienta de desarrollo basada en Objective-C de NeXT, Project Builder, que luego se ha expandido y ahora se conoce por Xcode, así como la herramienta de diseño de interfaz, Interface Builder. La mayoría de la actual Cocoa API de Apple está basada en objetos de interfaz de OneStep, y es el entorno de desarrollo de Objective-C más usado para desarrollo activo.

En la WWDC de 2014, Apple anunció planes para reemplazar a Objective-C en el desarrollo de Cocoa por el nuevo lenguaje Swift, que es llamado «Objective-C sin la C».

Sintaxis

Objective-C consiste en una capa muy fina situada por encima de C, y además es un estricto superconjunto de C. Esto es, es posible compilar cualquier programa escrito en C con un compilador de Objective-C, y también puede incluir libremente código en C dentro de una clase de Objective-C.

Esto es, para escribir el programa clásico "Hola Mundo" para correr en consola, se puede utilizar el siguiente código:

#import <stdio.h>
int main( int argc, const char *argv[] ) {
    printf( "Hola Mundo\n" );
    return 0;
}

El código anterior se diferencia de un código en C común por la primera instrucción #import, que difiere del #include del C clásico, pero la función printf("") es puramente C. La función propia de Objective-C para imprimir una cadena de caracteres en consola es NSLog(@"") utilizándola, el código anterior quedaría de la siguiente manera:

int main( int argc, const char *argv[] ) 
{
    NSLog( @"Hola Mundo\n" );
    return 0;
}

La sintaxis de objetos de Objective-C deriva de Smalltalk. Toda la sintaxis para las operaciones no orientadas a objetos, incluyendo variables primitivas, pre-procesamiento, expresiones, declaración de funciones y llamadas a funciones, son idénticas a las de C, mientras que la sintaxis para las características orientadas a objetos es una implementación similar a la mensajería de Smalltalk.

Mensajes

El modelo de programación orientada a objetos de Objective-C se basa en enviar mensajes a instancias de objetos. Esto es diferente al modelo de programación al estilo de Simula, utilizado por C++ y esta distinción es semánticamente importante. En Objective-C uno no llama a un método; uno envía un mensaje, y la diferencia entre ambos conceptos radica en cómo el código referido por el nombre del mensaje o método es ejecutado. En un lenguaje al estilo Simula, el nombre del método es en la mayoría de los casos atado a una sección de código en la clase objetivo por el compilador, pero en Smalltalk y Objective-C, el mensaje sigue siendo simplemente un nombre, y es resuelto en tiempo de ejecución: el objeto receptor tiene la tarea de interpretar por sí mismo el mensaje. Una consecuencia de esto es que el mensaje del sistema que pasa no tiene chequeo de tipo: el objeto al cual es dirigido el mensaje —conocido como receptor— no está inherentemente garantizado a responder a un mensaje, y si no lo hace, simplemente lo ignora y retorna un puntero nulo.

Enviar el mensaje method al objeto apuntado por el puntero obj requeriría el siguiente código en C++:

obj->method(parameter);

mientras que en Objective-C se escribiría como sigue:

[obj method:parameter];

Ambos estilos de programación poseen sus fortalezas y debilidades. La POO al estilo Simula permite herencia múltiple y rápida ejecución utilizando vinculación en tiempo de compilación siempre que sea posible, pero no soporta vinculación dinámica por defecto. Esto fuerza a que todos los métodos posean su correspondiente implementación, al menos que sean virtuales. Aun así, se requiere una implementación del método para efectuar la llamada. La POO al estilo Smalltalk permite que los mensajes no posean implementación - por ejemplo, toda una colección de objetos pueden enviar un mensaje sin temor a producir errores en tiempo de ejecución. El envío de mensajes tampoco requiere que un objeto sea definido en tiempo de compilación. Ver más abajo la sección tipado dinámico para más ventajas de la ligadura dinámica.

Sin embargo, se debe notar que debido a la sobrecarga de la interpretación de los mensajes, un mensaje en Objective-C toma, en el mejor de los casos, tres veces más tiempo que una llamada a un método virtual en C++.​

Interfaces e implementaciones

Objective-C requiere que la interfaz e implementación de una clase estén en bloques de código separados. Por convención, la interfaz es puesta en un archivo cabecera y la implementación en un archivo de código; los archivos cabecera, que normalmente poseen el sufijo .h, son similares a los archivos cabeceras de C; los archivos de implementación —método—, que normalmente poseen el sufijo .m, pueden ser muy similares a los archivos de código de C.

Interfaz

La interfaz de la clase es usualmente definida en el archivo cabecera. Una convención común consiste en nombrar al archivo cabecera con el mismo nombre de la clase. La interfaz para la clase Clase debería, así, ser encontrada en el archivo Clase.h.

La declaración de la interfaz de la forma:

@interface classname : superclassname 
{
    // instance variables
}
+classMethod1;
+(return_type)classMethod2;
+(return_type)classMethod3:(param1_type)parameter_varName;

-(return_type)instanceMethod1:(param1_type)param1_varName :(param2_type)param2_varName;
-(return_type)instanceMethod2WithParameter:(param1_type)param1_varName andOtherParameter:(param2_type)param2_varName;
@end

Los signos más denotan métodos de clase, los signos menos denotan métodos de instancia. Los métodos de clase no tienen acceso a las variables de la instancia.

Si usted viene de C++, el código anterior es equivalente a algo como esto:

class classname : superclassname 
{
  public:
    // instance variables
    
    // Class (static) functions
    static void* classMethod1();
    static return_type classMethod2();
    static return_type classMethod3(param1_type parameter_varName);
    
    // Instance (member) functions
    return_type instanceMethod1(param1_type param1_varName, param2_type param2_varName);
   return_type instanceMethod2WithParameter(param1_type param1_varName, param2_type param2_varName = default);
};

Note que instanceMethod2WithParameter demuestra la capacidad de nombrado de parámetro de Objective-C para la cual no existe equivalente directo en C/C++.

Los tipos de retorno pueden ser cualquier tipo estándar de C, un puntero a un objeto genérico de Objective-C, o un puntero a un tipo específico así como NSArray *, NSImage *, o NSString *. El tipo de retorno por defecto es el tipo genérico id de Objective-C.

Los argumentos de los métodos comienzan con dos puntos seguidos por el tipo de argumento esperado en los paréntesis seguido por el nombre del argumento. En algunos casos (por ej. cuando se escriben APIs de sistema) es útil agregar un texto descriptivo antes de cada parámetro.

-(void) setRangeStart:(int)start End:(int)end;
-(void) importDocumentWithName:(NSString *)name withSpecifiedPreferences:(Preferences *)prefs beforePage:(int)insertPage;

Implementación

La interfaz únicamente declara la interfaz de la clase y no los métodos en sí; el código real es escrito en la implementación. Los archivos de implementación (métodos) normalmente poseen la extensión .m.

@implementation classname
+classMethod {
    // implementation
}
-instanceMethod {
    // implementation
}
@end

Los métodos son escritos con sus declaraciones de interfaz. Comparando Objective-C y C:

-(int)method:(int)i 
{
    return [self square_root: i];
}

int function(int i) 
{
    return square_root(i);
}

La sintaxis admite pseudo-nombrado de argumentos.

-(int)changeColorToRed:(float)red green:(float)green blue:(float)blue

[myColor changeColorToRed:5.0 green:2.0 blue:6.0];

La representación interna de este método varía entre diferentes implementaciones de Objective-C. Si myColor es de la clase Color, internamente, la instancia del método -changeColorToRed:green:blue: podría ser etiquetada como _i_Color_changeColorToRed_green_blue. La i hace referencia a una instancia de método, acompañado por los nombres de la clase y el método, y los dos puntos son reemplazados por guiones bajos. Como el orden de los parámetros es parte del nombre del método, éste no puede ser cambiado para adaptarse al estilo de codificación.

De todos modos, los nombres internos de las funciones son raramente utilizadas de manera directa, y generalmente los mensajes son convertidos a llamadas de funciones definidas en la librería en tiempo de ejecución de Objective-C – el método que será llamado no es necesariamente conocido en tiempo de vinculación: la clase del receptor, el objeto que envió el mensaje, no necesita conocerlo hasta el tiempo de ejecución.

Instanciación

Una vez que una clase es escrita en Objective-C, puede ser instanciada. Esto se lleva a cabo primeramente alojando la memoria para el nuevo objeto y luego inicializándolo. Un objeto no es completamente funcional hasta que ambos pasos sean completados. Esos pasos típicamente se logran con una simple línea de código:

MyObject * o = [[MyObject alloc] init];

La llamada a alloc aloja la memoria suficiente para mantener todas las variables de instancia para un objeto, y la llamada a init puede ser anulada para establecer las variables de instancia con valores específicos al momento de su creación. El método init es escrito a menudo de la siguiente manera:

-(id) init 
{
    self = [super init];
    if (self) 
    {
        ivar1 = '''value1''';
        ivar2 = value2;
        .
        .
        .
    }
    return self;
}

Protocolos

Objective-C fue extendido en NeXT para introducir el concepto de herencia múltiple de la especificación, pero no la implementación, a través de la introducción de protocolos. Este es un modelo viable, ya sea como una clase base abstracta multi-heredada en C++, o como una «interfaz», como en Java o C#. Objective-C hace uso de protocolos ad hoc, llamados protocolos informales, y el compilador debe cumplir los llamados protocolos formales.

Tipado dinámico

Objective-C, al igual que Smalltalk, puede usar tipado dinámico: un objeto puede recibir un mensaje que no está especificado en su interfaz. Esto se permite para incrementar la flexibilidad, ya que permite a un objeto "capturar" un mensaje y enviarlo a otro objeto diferente que pueda responder a ese mensaje apropiadamente, o del mismo modo reenviar el mensaje a otro objeto. Este comportamiento es conocido como reenvío de mensajes o delegación (ver más abajo). Alternativamente, un manejo de error puede ser usado en caso de que el mensaje no pueda ser reenviado. Si un objeto no reenvía un mensaje, lo responde o maneja un error entonces el sistema generará una excepción en tiempo de ejecución. Si los mensajes son enviados a nil, el puntero de objetos nulo, serán ignorados silenciosamente o elevarán una excepción genérica, dependiendo de las opciones del compilador.

La información tipada estáticamente puede ser añadida opcionalmente a variables. Esta información es luego comprobada a la hora de compilar. En las siguientes cuatro declaraciones se proveen tipos de información crecientemente específicos. Estas declaraciones son equivalentes en el tiempo de ejecución, pero la información adicional permite al compilador el avisar al programador si el argumento pasado no encaja con el tipo especificado.

- (void)setMyValue:(id)foo;

En la declaración anterior, foo puede ser de cualquier clase.

- (void)setMyValue:(id<NSCopying>)foo;

En la declaración anterior, foo puede ser una instancia de cualquier clase que satisfaga al protocolo NSCopying.

- (void)setMyValue:(NSNumber *)foo;

En la declaración anterior, foo debe ser una instancia de la clase NSNumber.

- (void)setMyValue:(NSNumber<NSCopying> *)foo;

En la declaración anterior, foo debe ser una instancia de la clase NSNumber, y debe satisfacer al protocolo NSCopying.

Reenvío

Objective-C permite el envío de un mensaje a un objeto que puede no responder. En lugar de responder o simplemente ignorar el mensaje, un objeto puede reenviar el mensaje a otro objeto que pueda responderlo. El reenvío puede ser usado para simplificar la implementación de ciertos patrones de diseño, como el observer o el proxy.

El tiempo de ejecución de Objective-C especifica un par de métodos en Object:

• métodos de reenvío:

- (retval_t)forward:(SEL)sel args:(arglist_t)args; // con GCC
- (id)forward:(SEL)sel args:(marg_list)args; // con sistemas NeXT/Apple

• métodos de acción:

- (retval_t)performv:(SEL)sel args:(arglist_t)args; // con GCC
- (id)performV:(SEL)sel args(marg_list)args; // con sistemas NeXT/Apple

Un objeto que desee implementar el reenvío solamente necesita sobreescribir el método de reenvío con un nuevo método que defina el comportamiento de reenvío. El método de acción performv:: no necesita ser sobreescrito, ya que este método meramente realiza una acción basada en el selector y los argumentos. El tipo SEL es el tipo de mensajes en Objective-C.

Nota: en openStep, Cocoa y GNUstep, los espacios de trabajo de Objective-C comúnmente usados, no hay que usar la clase Object. el método - (void)forwardInvocation:(NSInvocation *)anInvocation de la clase NSObject es usado para realizar el reenvío.

Ejemplo

Aquí hay un ejemplo de un programa que demuestra las bases del reenvío.

Forwarder.h

# import <objc/Object.h>

@interface Forwarder : Object {
 id recipient; // El objeto al que queremos reenviar el mensaje.
}

// Métodos de acceso
- (id)recipient;
- (id)setRecipient:(id)_recipient;

@end

Forwarder.m

# import "Forwarder.h"
 
@implementation Forwarder
 
- (retval_t)forward:(SEL)sel args:(arglist_t) args {
 /*
  * Comprueba si el receptor responde al mensaje.
  * Esto puede ser o no deseable, por ejemplo, si un receptor
  * a su vez no responde el mensaje, podría reenviarlo él mismo.
  */
 if([recipient respondsToSelector:sel]) {
  return [recipient performv:sel args:args];
 } else {
  return [self error:"El receptor no responde"];
 }
}
 
- (id)setRecipient:(id)_recipient {
 [recipient autorelease];
 recipient = [_recipient retain];
 return self;
}
 
- (id) recipient {
 return recipient;
}
@end

Recipient.h

# import <objc/Object.h>
 
// Un simlpe objeto receptor.
@interface Recipient : Object
- (id)hola;
@end

Recipient.m

# import "Recipient.h"
 
@implementation Recipient
 
- (id)hola {
 printf("El receptor dice hola!\n");
 
 return self;
}
 
@end

main.m

# import "Forwarder.h"
# import "Recipient.h"
 
int main(void) {
 Forwarder *forwarder = [Forwarder new];
 Recipient *recipient = [Recipient new];
 
 [forwarder setRecipient:recipient]; // Elige el receptor.
 /*
  * Véase que el reenviante no ersponda al saludo! Será reenviado.
  * Todos los métodos no reconocidos serán reenviados al receptor
  * (si el receptor los responde, como se dice en el Forwarder)
  */
 [forwarder hello];
 
 [recipient release];
 [forwarder release];
 
 return 0;
}

Notas

Cuando se compila con gcc, el compilador reporta:

$ gcc -x objective-c -Wno-import Forwarder.m Recipient.m main.m -lobjc

main.m: In function `main':

main.m:12: warning: `Forwarder' no responde a `hola'

$

El compilador reporta lo comentando antes, que Forwarder no responde a mensajes hola. En esta circunstancia, es seguro ignorar el aviso ya que el reenvío fue implementando. La ejecución del programa produce esta salida:

& ./a.out

El receptor dice hola!

Variantes del lenguaje

Objective-C++

Objective-C++ es una variante del lenguaje aceptada por la interfaz del GNU Compiler Collection y Clang, que puede compilar archivos de código fuente que usen una combinación de sintaxis de C++ y Objective-C. Objective-C++ añade a C++ las extensiones que Objective-C añade a C. Como no se hace nada para unificar la semántica detrás de las características de varios lenguajes, existen ciertas restricciones:

• Una clase de C++ no puede derivar de una clase de Objective-C y viceversa.
• Espacios de nombres de C++ no pueden ser declarados dentro de una declaración de Objective-C.
• Las declaraciones de Objective-C deben aparecer de manera global, no dentro de una declaración de C++.
• Las clases de Objective-C no pueden tener instancias variables de clases de C++ que no tengan un constructor por defecto o que tengan uno o más métodos virtuales, pero los punteros a objetos de C++ pueden ser usados como instancias variables sin restricción, se asignan en el método -init.
• Las semánticas "por valor" de C++ no pueden ser aplicadas a objetos de Objective-C, que solamente son accesibles mediante punteros.
• Una declaración de Objective-C no puede estar dentro de una plantilla de declaración de C++ y viceversa. Sin embargo, los tipos de Objective-C, como Classname *, pueden ser usados como parámetros de plantillas de C++.
• El manejo de excepciones de Objective-C y C++ es distinto; cada lenguaje solamente puede manejar excepciones propias. Esto es mitigado en recientes versiones o bien reemplazando completamente las exceptiones de Objective-C por excepciones de C++, como hace Apple, o parcialmente cuando está enlacada la librería de Objective-C++, GNUstep libobjc2.
• Hay que tener cuidado ya que las llamadas al destructor de las excepciones en tiempo de ejecución de Objective-C y C++ no coinciden. Por ejemplo, un destructor de C++ no será llamado cuando una excepción de Objective-C sale del alcance de un objeto de C++. Las nuevas versiones de 64 bits solucionan esto mediante la introducción de interoperabilidad con las excepciones de C++ en este sentido.​
• Los blocks de Objective-C y las lambdas de C++11 son entidades distintas, sin embargo un block es generado transparentemente en Mac OS X cuando se pasa una lambda donde se espera un block.​

Objective-C 2.0

En la Worldwide Developers Conference de 2006, Apple anunció el lanzamiento de "Objective-C 2.0", una revisión del lenguaje Objective-C para incluir "una recolección de basura moderna, mejoras de sintaxis,​ perfeccionamiento de la ejecución​ y soporte para 64 bits". Mac OS X v10.5, lanzado en octubre de 2007, incluía un compilador de Objective-C 2.0. GCC 4.6 soporta muchas aplicaciones nuevas de Objective-C, como las propiedades declaradas y sintetizadas, sintaxis de puntos, enumeración rápida, métodos de protocolo opcionales, atributos de método/protocolo/clase, extensiones de clase y una nueva API de GNUnn Objective-C.​

Recolección de basura

Objective 2.0 contaba con un recolector de basura conservativo opcional. Cuando se ejecutaba en modo de retrocompatibilidad, cambiaba las operaciones de conteo de referencias como «retener» y «liberar» en NOPs, o sea No operaciones, instrucción de ensamblador que indica que el procesador no tiene que hacer nada. Todos los objetos eran sometidos al recolector de basura cuando la recolección de basura estaba habilitada. Los punteros de C podían ser cualificados con "__strong" para provocar la intercepción de escritura del compilador y así participar en la recolección de basura.​ Un subsistema débil de puesta a cero también era provisto de tal manera que los punteros marcados con "__weak" eran puestos a cero cuando el objeto —o más fácilmente, la memoria del recolector de basura— es recolectado. El recolector de basura no existía en la implementación de Objective-C 2.0 de iOS.​ La recolección de basura en Objective-C se ejecuta en un hilo de baja prioridad y puede detener eventos del usuario, con la intención de mantener la experiencia del usuario receptiva.​

La recolección de basura nunca estuvo disponible en iOS debido a problemas de rendimiento. Fue despreciado en la versión 10.8 de OS X en favor del Conteo de Referencias Automático, o Automatic Reference Counting —ARC— en inglés, y está programado que se elimine en una futura versión de OS X.​ Objective-C en iOS 7 ejecutado en ARM64 usa 19 bits de una palabra de 64 bits para almacenar el conteo de referencias, como una forma de puntero etiquetado.​​

Propiedades

Objective 2.0 introduce una nueva sintaxis para declarar variables de instancia como propiedades, con atributos opcionales para configurar la generación de métodos de acceso. Las propiedades son, en cierto sentido, variables de instancia públicas; esto es, declarar una variable de instancia como una propiedad provee a clases externas de acceso (posiblemente limitado, como por ejemplo solo lectura) a esa propiedad. Una propiedad puede ser declarada como "readonly" (solo lectura) y puede ser provista de semántica de almacenamiento como "assign" (asignar), "copy" (copiar) o "retain" (retener). Por defecto, las propiedades son consideradas atómicas, que resulta en un seguro para prevenir a múltiples hilos que accedan a ella al mismo tiempo. Una propiedad puede ser declarada como "nonatomic" (no atómica), que elimina este seguro.

@interface Persona : NSObject {
 @public
 NSString *nombre;
 @private
 int edad;
}

@property(copy) NSString *nombre;
@property(readonly) int edad;

-(id)iniciarConEdad:(int)edad;
@end

Las propiedades son implementadas mediante la palabra clave @synthesize, que genera los métodos getter (y setter, si no son de solo lectura) de acuerdo a la declaración de la propiedad. Alternativamente, los métodos getter y setter deben ser implementados explícitamente, o la palabra clave @dynamic puede ser usada para indicar que los métodos de acceso deben ser provistos por otros medios. Cuando se compila usando Clang 3.1 o superior, todas las propiedades que no estén explícitamente declaradas con @dynamic, no estén marcadas readonly o no tengan los métodos completos implementados por el usuario getter y setter, serán automáticamente declaradas @synthesize de manera implícita.

@implementation Persona
@synthesize nombre;

-(id)iniciarConEdad:(int)edadInicial {
 self = [super inicial];
 if (self) {
 edad = edadInicial; // NOTA: asignación directo de la variable de instancia, no propiedad setter
 }
 return self;
}

-(int)edad {
 return edad;
}
@end

Las propiedades pueden ser accedidas usando la sintaxis tradicional de paso de mensajes, notació por puntos o, en Codificación Key-Value, mediante los métodos valueForKey:/setValue:forKey.

Persona *unaPersona = [[Persona alloc] iniciarConEdad: 53];
unaPersona.nombre = @"Steve"; // NOTA: la notación por puntos, usa el setter sintetizado,
 // equivalente a [unaPersona setNombre: @"Steve"];
NSLog(@"Acceso por mensaje (%@), notación por puntos(%@),
nombre de propiedad(%@) y acceso directo a la variabled e instancia (%@)",
 [unaPersona nombre], unaPersona.nombre, [unaPersona valueForKey:@"nombre"], unaPersona->nombre);

Para que el uso de notación por puntos invoque a las propiedades de acceso en un método de instancia, la palabra clave "self" debe ser usada:

-(void) presentarmeConPropiedades:(BOOL)useGetter {
 NSLog(@"Hola, mi nombre es %@.", (useGetter ? self.nombre : nombre));
// NOTA: getter vs. acceso ivar
}

Una clase o las propiedades de protocolo pueden ser introspeccionadas dinámicamente.

int i;
int contadorPropiedades = 0;
objc_propiedad_t *listaPropiedades = clase_copiarListaPropiedades([unaPersona class], &contadorPropiedades);

for (i = 0; i < contadorPropiedades; i++) {
 objc_propiedad_t *estaPropiedad = listaPropiedades + i;
 const char* nombrePropiedad = propiedad_getNombre(*estaPropiedad);
 NSLog(@"Persona tiene una propiedad: '%s'", nombrePropiedad);
}

Variables de instancia no frágiles

Objective-C 2.0 provee de variables de instancia no frágiles soportadas por el entorno de ejecución (por ejemplo, creando código para un Mac OS X de 64 bits así como código para todos los iOS). Bajo el entorno de ejecución moderno, una capa extra de sesgo es añadida para instanciar variables de acceso, permitiendo al enlazador dinámico ajustar el plano de instanciaciones en tiempo de ejecución. Esta propiedad permite dos grandes mejoras en el código Objective-C:

• Elimina el problema de la fragilidad de interfaces binarias - las superclases pueden cambiar su tamaño sin afectar a la compatibilidad binaria.
• Permite que las variables de instancia que proveen retrocompatibilidad para las propiedades puedan ser sintetizadas en el tiempo de ejecución sin que estén declaradas en la interfaz de la clase.

Enumeración rápida

En lugar de usar un objeto NSEnumerator o indicar la iteración a lo largo de una colección, Objective-C 2.0 ofrece la sintaxis de enumeración rápida. En Objective-C 2.0, los siguientes bucles son funcionalmente equivalentes, pero tienen diferentes características de rendimiento.

// Usando NSEnumerator
NSEnumerator *enumerador = [laGente objectEnumerator];
Persona *p;

while ((p = [enumerador nextObject]) != nil) {
 NSLog(@"%@ tiene %i años.", [p nombre], [p edad]);
}

// Usando índices
for (int i = 0; i < [laGente count]; i++) {
 Persona *p = [laGente objectAtIndex:i];
 NSLog(@"%@ tiene %i años.", [p nombre], [p edad]);
}

// Using enumeración rápida
for (Persona *p in laGente) {
 NSLog(@"%@ tiene %i años.", [p nombre], [p edad]);
}

La enumeración rápida genera código más eficiente que la enumeración estándar porque las llamadas a los métodos para enumerar objetos son reemplazadas por aritmética de punteros usando el protocolo NSFastEnumeration.

Extensión de clases

Una extensión de clase tiene el mismo sintaxis que una declaración de categoría sin nombre de categoría y los métodos y propiedades declarados en ella son añadidos directamente a la clase main. Es sobre todo usado como una alternativa a una categoría el añadir métodos a una clase sin declararlos en las cabeceras públicas, con la ventaja de que para las extensiones de clase el compilador comprueba que todos los métodos declarados privadamente son implementados realmente.​

Blocks

Blocks es una extensión no estándar para Objective-C (así como para C y C++) que usa una sintaxis especial para crear clausuras. Blocks solo está soportado en Mac OS X 10.6 "Snow Leopard" o superior y en iOS 4 o superior, así como en GNUstep con libobjc2 1.7 y compilado con Clang 3.1 o superior.​

#include <stdio.h>
#include <Block.h>
typedef int (^IntBlock)();

IntBlock MakeCounter(int start, int increment) {
	__block int i = start;
	
	return Block_copy( ^ {
		int ret = i;
		i += increment;
		return ret;
	});
	
}

int main(void) {
	IntBlock mycounter = MakeCounter(5, 2);
	printf("First call: %d\n", mycounter());
	printf("Second call: %d\n", mycounter());
	printf("Third call: %d\n", mycounter());
	
	/* because it was copied, it must also be released */
	Block_release(mycounter);
	
	return 0;
}
/* Output:
	First call: 5
	Second call: 7
	Third call: 9
*/

Modern Objective-C

Automatic Reference Counting

Automatic Reference Counting (Conteo Automático de Referencias, ARC) es una característica del tiempo de compilación que elimina la necesidad de que los programadores tengan que guardar manualmente cuentas usando retain y release.​ Al contrario que el recolector de basura, que funciona en tiempo de ejecución, el ARC elimina la sobrecarga de un proceso separado al gestionar la retención de las cuentas. El ARC y el manejo manual de memoria no son mutualmente excluyentes; los programadores pueden continuar usando código no ARC en proyectos que tienen el ARC activado mediante la desactivación del ARC para códigos fuente individuales. Xcode también puede tratar de actualizar automáticamente un proyecto a ARC.

Literales

Los entornos de ejecución NeXT y Apple Obj-C incluyeron hace tiempo un atajo para crear nuevas cadenas, usando la sintaxis literal @"una nueva cadena" y también desecharon las constantes de CoreFoundation kCFBooleanTrue y kCFBooleanFalse por la variable NSNUmber con valores booleanos. Al usar este formato se libera al programador de usar el más largo initWithString o métodos similares al hacer ciertas operaciones.

Cuando se usa el compilador de Apple LLVM 4.0 o superior, vectores, diccionarios y números (las clases NSAray, NSDictionary y NSNumber) pueden ser también creados usando sintaxis literal en lugar de métodos.​ La sintaxis literal usa el símbolo @ combinado con [], {} o () para crear las clases mencionadas anteriormente, respectivamente.​

Ejemplo sin literales:

NSArray *miVector = [NSArray arrayConObjectos:objeto1,objeto2,objeto3,nil];
NSDictionary *miDiccionario1 = [NSDictionary diccionarioConObjeto:unObjeto forKey:@"llave"];
NSDictionary *miDiccionario2 = [NSDictionary diccionarioConObjetosYLlaves:objeto1, llave1, objeto2, llave2, nil];
NSNumber *miNumero = [NSNumber numeroConInt:miInt];
NSNumber *miNumeroSuma = [NSNumber numeroConInt:(2 + 3)];
NSNumber *miNumeroBooleano = [NSNumber numeroConBooleano:YES];

Ejemplo con literales:

NSArray *myVector = @[ objeto1, objeto2, objeto3 ];
NSDictionary *miDiccionario1 = { @"llave" : unObjeto };
NSDictionary *miDiccionario2 = { llave1: objeto1, llave2: objeto2 };
NSNumber *miNumero = @{miInt};
NSNumber *miNumeroSuma = @{2+3};
NSNumber *miNumeroBooleano = @YES;

Sin embargo, al contrario que las cadenas literales que se compilan como constantes en el ejecutable, estos literales se compilan como código equivalente a las llamadas a métodos mencionadas arriba. En particular, bajo manejo manual del conteo de referencia de memoria, estos objetos son autoliberados, lo que requiere especial cuidado cuando por ejemplo son usados con variables de funciones estáticas o otros tipos de variables globales.

Subíndices

Cuando se usa el compilador de Apple LLVM 4.0 o superior, vectores y diccionarios (las clases NSArray y NSDictionary) pueden ser manipuladas usando subíndices.​ Los subíndices se pueden usar para recuperar valores de índices (vectores) o llaves (diccionarios) y con objetos mutables también puede user para fijar objetos a índices o llaves. En el código, los subíndices son representados usando corchetes [ ].​

Ejemplos sin subíndices:

id objeto1 = [unVector objectAtIndex:0];
id objeto2 = [unDiccionario objectForKey:@"llave"];
[unVectorMutable replaceObjectAtIndex:0 withObject:objeto3];
[unDiccionarioMutable setObject:objeto4 forKey:@"llave"];

Ejemplos con subíndices:

id objeto1 = unVector[0];
id objeto2 = unDiccionario[@"llave"];
unVectorMutable[0] = objeto3;
unDiccionarioMutable[@"llave"] = objeto4;

Sintaxis de Objective-C "Moderna" (1997)

Tras la compra de NeXT por parte de Apple, se hicieron varios intentos para asemejar más el lenguaje con respecto a otros lenguajes existentes. Uno de estos intentos fue la introducción de lo que se denominó en su momento "Sintaxis moderna" para Objective-C (en oposición a la existente, sintaxis "clásica"). No había cambios en el comportamiento real, simplemente era una sintaxis alternativa. La invocación a un método se hacía de este modo:

objeto = (MiClase.alloc).init;
objeto.primeraEtiq ( param1, param2 );

Y pasó a escribirse de este otro modo:

objeto = [[MiClase alloc] init];
[objeto primeraEtiq: param1 segundaEtiq: param2];

Similarmente, las declaraciones pasaron de ser así:

-(void) primeraEtiq ( int param1, int param2 );

a ser así:

-(void) primeraEtiq: (int)param1 segundaEtiq: (int)param2;

Esta sintaxis "moderna" no está soportada en dialectos actuales de Objective-C.

Portable Object Compiler

Además de las implementaciones de GCC/NeXT/Apple, que añadieron varias extensiones a la implementación original de Stepstone, también existe otra implementación libre y abierta de Objective-C llamada Protable Object Compiler.​ El conjunto de extensiones implementadas por el Portable Object Compiler difiere de las implementaciones GCC/NeXT/Apple; en particular, incluye blocks similares a los de Smalltalk para Objective-C, mientras que carece de protocolos y categorías, dos características usadas ampliamente en OpenStep y sus derivados. En conjunto, POC representa una etapa vieja, pre-NeXT, de la evolución del lenguaje, simplemente conforme al libro de 1991 de Brad Cox.

También incluye una librería de tiempo de ejecución llamada ObjectPak, que está basada en la librería original ICPak101 de Cox (que a su vez deriva de la librería de clases Smalltalk-80) y es radicalmente diferente a la de OneStep FoundationKit.

GEOS Objective-C

El sistema PC GEOS usaba un lenguaje de programación conocido como GEOS Objective-C o goc;​ a pesar de su similar nombre, los dos lenguajes son similares en un concepto global y por el uso de palabras clave precedidas por el signo @.

Clang

La suite de compiladores Clang, parte del proyecto LLVM, implementa Objective-C así como otros lenguajes.

Véase también

• Xcode
• Mac OS X
• Java
• Smalltalk
• C
• C++

Enlaces externos

• Página de Apple sobre Objective-C.
• Comunidad de programadores Mac OS X.
• El lenguaje Objective-C para programadores C++ y Java.
• "Hola Mundo" en Objective-C para el iPhone.

• Datos: Q188531
• Multimedia: Objective-C / Q188531