Twoixted againLet’s get twoixted again…

Hacía muchos años que no veía ObjectiveC. Cuando digo muchos, digo muuuchos. No me equivocaría si dijera que aún estaba en venta el NeXT…

Ahora he vuelto a verlo por el iPhone. La verdad es que es la primera vez que me acerco en serio a la programación para OSX. No me acordaba desde mis tiempos de universidad, y de eso ha llovido un poco. Lo más que me acuerdo es que era en C y con un Classic… cuando era actual, jajaja.

Odio la programación en ObjectiveC. Puedo comprender las razones de Apple por elegir un lenguaje así en su época, pero no para mantenerlo. Es cierto que usar C/C++ para programación de entornos de usuario hay malos ejemplos, aunque se puede hacer bien, o hacer muy bien. También podía haber hecho su propio lenguaje, o ampliar uno ya existente. Ya puestos, por qué no usar directamente SmallTalk.

Dejemoslo claro, esto es una opinión personal. Si alguien lee esto que es defensor a ultranza de ObjectiveC le daré la razón. Simplemente quiero decir que no se piense que es una opinión de “Newbe”, llevo programando en entornos de usuario desde que me compré el número 1 del MSJ (Microsoft System Journal).

De hecho, lo malo no es el entorno de desarrollo, el Xcode lo considero fenomenal, un entorno de desarrollo que ya quisiera en Windows. No. Lo malo es con el lenguaje.

En cuanto a la sintaxis es lo de menos, al final te acostumbras aunque duramente por tantos años llamando a las funciones.con().parentesis(). Lo malo de la sintaxis de ObjectiveC es justamente lo lioso de leer y de entender para los no iniciados. Te [puedes [perder facilmente:@"en la" [maraña init]]]

Para mi lo peor es que es un lenguaje orientado a objetos sobre uno que no lo es, como C. Aunque en ObjectiveC++ se pueden mezclar clases de C++ con ObjectiveC, esto no arregla el problema. Esta diferencia de conceptos ha llevado a un lenguaje que no tiene constructores y destructores, no tiene sobrecarga de operadores ni polimorfismo, entre otras cosas.

Ahora que hay más movimiento en la programación ObjectiveC por el iPhone, se oyen voces de programadores contra el sistema, y se necesitan posts como este simplemente para decir cómo se tiene que construir un puto objeto en cocoa! Simplemente esto no me parece serio, y voy a dar una razón que creo de peso: no es de recibo que un lenguaje orientado a objetos, por mucho recolector de basura que tenga, sea tan propenso a equivocaciones.

El ejemplo de los constructores. En ObjectiveC no hay constructores ni destructores. Punto. Los objetos se inicializan si el programador se acuerda de hacerlo. Todo esto sin contar que toda la jerarquía de objetos que estás construyendo depende de que tu llames a [objeto init]. Me suena a tremendo WTF!. Si hablamos de destructores, la cosa se complica. Es el programador el que tiene que llamar a “dealloc” para destruir un objeto. No, espera, ¿o mejor llamar a “release”? Mmhh… Depende. Es a estas cosas a las que me refiero, el lenguaje no permite una construcción robusta de librerías. No basta con poner en negrita en rojo con fondo fosforito en la documentación: “Llama al puto release cuando quieras liberarme”, es la clase la que debería asegurarse de liberar sus recursos.

Me recuerdo ahora un post que leí en un blog, no recuerdo el nombre si no lo pondría, que venía a decir algo así con respecto a los destructores:

“En ObjectiveC no hace falta destruir un objeto, normalmente es más sencillo y mejor que el sistema operativo libere la memoria cuando sale del programa, excepto si el objeto tiene recursos ocupados como ficheros abiertos.”.

En resumiendo venía a decir algo así. Para mi mente tan Stroustruptiana, simplemente no cabe en la cabeza que algún programador (quizás yo mismo) me deje recursos sin liberar. Llamalo memoria, en tal caso viene la basura y me la recoje, pero llámalo fichero abierto, llámalo socket conectado o peor aún, llámalo semáforo activo y verás el problema.

Este es uno de los posts que iré poniendo conforme vaya descubriendo ObjectiveC, quizá los siguientes sean más compasivos, pero mientras tanto, y si vas a escribir un comentario negativo, resuelve esta cuestión:

¿Cual es la forma más correcta de inicializar un objeto?

Forma número 1:

1
2
3
4
5
6

- (id)init {
    if ((self = [super init])) {
        // inicializar el objeto.
    }
    return self;
}

Forma número 2:

1
2
3
4
5

- (id)init {
    if (![self init]) return nil;
 
    // Inicializar el objeto
}