¿Por qué la última parte del nombre de un método de Objective-C debe tomar un argumento (cuando hay más de una parte)?

En Objective-C, no puede declarar nombres de métodos donde el último componente no toma un argumento. Por ejemplo, lo siguiente es ilegal.

-(void)take:(id)theMoney andRun;
-(void)take:(id)yourMedicine andDontComplain;

¿Por qué Objective-C fue diseñado de esta manera? ¿Era solo un artefacto de Smalltalk del que nadie vio la necesidad de deshacerse?

Esta limitación tiene sentido en Smalltalk, ya que Smalltalk no tiene delimitadores alrededor de la invocación de mensajes, por lo que el componente final se interpretaría como un mensaje unario para el último argumento. Por ejemplo, BillyAndBobby take:'$100' andRunse analizaría como BillyAndBobby take:('$100' andRun). Esto no importa en Objective-C, donde se requieren corchetes.

Admitir componentes de selector sin parámetros no nos beneficiaría mucho en todas las formas habituales en que se mide un lenguaje, ya que el nombre del método que elige un programador (por ejemplo, en runWith:lugar detake:andRun) no afecta la semántica funcional de un programa, ni la expresividad del lenguaje. De hecho, un programa con componentes sin parámetros es alfa equivalente a uno sin ellos. Por lo tanto, no me interesan las respuestas que indiquen que tal característica no es necesaria (a menos que esas fueran las razones declaradas por los diseñadores de Objective-C; ¿alguien conoce a Brad Cox o Tom Love? ¿Están aquí?) O que digan cómo escribir nombres de métodos para que la función no sea necesaria. El beneficio principal es la legibilidad y la capacidad de escritura (que es como la legibilidad, solo ... ya sabes), ya que significaría que podrías escribir nombres de métodos que se parezcan aún más a las oraciones del lenguaje natural. Los gustos de -(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication*)theApplication(que Matt Gallagher señala en "Cocoa With Love"-(BOOL)application:(NSApplication*)theApplication shouldTerminateAfterLastWindowClosed, colocando así el parámetro inmediatamente al lado del sustantivo apropiado.

El tiempo de ejecución Objective-C de Apple (por ejemplo) es perfectamente capaz de manejar este tipo de selectores, así que ¿por qué no el compilador? ¿Por qué no apoyarlos también en los nombres de los métodos?

#import <Foundation/Foundation.h>
#import <objc/runtime.h>

@interface Potrzebie : NSObject
-(void)take:(id)thing;
@end

@implementation Potrzebie
+(void)initialize {
    SEL take_andRun = NSSelectorFromString(@"take:andRun");
    IMP take_ = class_getMethodImplementation(self, @selector(take:));
    if (take_) {
        if (NO == class_addMethod(self, take_andRun, take_, "@@:@")) {
            NSLog(@"Couldn't add selector '%@' to class %s.", 
                  NSStringFromSelector(take_andRun), 
                  class_getName(self));
        }
    } else {
        NSLog(@"Couldn't find method 'take:'.");
    }
}

-(void)take:(id)thing {
    NSLog(@"-take: (actually %@) %@",NSStringFromSelector(_cmd), thing);
}
@end

int main() {
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    Potrzebie *axolotl=[[Potrzebie alloc] init];
    [axolotl take:@"paradichloroaminobenzaldehyde"];
    [axolotl performSelector:NSSelectorFromString(@"take:andRun") 
                  withObject:@"$100"];
    [axolotl release];

    [pool release];
    return 0;
}

Este es Brad Cox. Mi respuesta original entendió mal la pregunta. Asumí que realmenteFast era una extensión codificada para activar mensajes más rápidos, no una especie de azúcar sintáctico. La respuesta real es que Smalltalk no lo admitió, quizás porque su analizador no pudo lidiar con la ambigüedad (supuesta). Aunque los corchetes de OC eliminarían cualquier ambigüedad, simplemente no pensé en apartarme de la estructura de palabras clave de Smalltalk.

21 años de programación de Objective-C y esta pregunta nunca se me ha pasado por la cabeza. Dado el diseño del lenguaje, el compilador tiene razón y las funciones en tiempo de ejecución son incorrectas ().

La noción de argumentos intercalados con nombres de métodos siempre ha significado que, si hay al menos un argumento, el último argumento es siempre la última parte de la sintaxis de invocación del método.

Sin pensarlo mucho, apuesto a que hay algunos errores sintácticos con no hacer cumplir el patrón actual. Al menos, haría que el compilador fuera más difícil de escribir, ya que cualquier sintaxis que tenga elementos opcionales intercalados con expresiones siempre es más difícil de analizar. Incluso podría haber un caso de borde que lo impida. Ciertamente, Obj-C ++ lo haría más desafiante, pero eso no se integró con el lenguaje hasta años después de que la sintaxis base ya estuviera escrita en piedra.

En cuanto a por qué Objective-C se diseñó de esta manera, sospecho que la respuesta es que los diseñadores originales del lenguaje simplemente no consideraron permitir que la sintaxis intercalada vaya más allá de ese último argumento.

Esa es la mejor suposición. Le preguntaré a uno de ellos y actualizaré mi respuesta cuando sepa más.

Le pregunté a Brad Cox sobre esto y fue muy generoso al responder en detalle (¡Gracias, Brad!):

En ese momento estaba concentrado en duplicar tanto Smalltalk como fuera posible en C y hacerlo de la manera más eficiente posible. Cualquier ciclo de repuesto se utilizó para acelerar la mensajería ordinaria. No se pensó en una opción de mensajería especializada ("¿Realmente Rápido?" [ Bbum: pregunté usando 'hacer algo: con algo: realmente Rápido' como ejemplo ]) ya que los mensajes ordinarios ya eran tan rápidos como podían ser. Esto implicó ajustar manualmente la salida del ensamblador del proto-messager de C, que fue una pesadilla de portabilidad tal que parte de eso, si no todo, se eliminó más tarde. Sí recuerdo que el mensajero pirateado a mano fue muy rápido; sobre el costo de dos llamadas a funciones; uno para entrar en la lógica del mensajero y el resto para realizar búsquedas de métodos una vez allí.
Más tarde, Steve Naroff y otros agregaron mejoras en la escritura estática además de la escritura dinámica pura de Smalltalk. Solo tuve una participación limitada en eso.

¡Ve a leer la respuesta de Brad!

Solo para su información, al tiempo de ejecución no le importan los selectores, cualquier cadena C es válida, también podría hacer un selector como ese: "== + === + ---__-- ¨¨¨¨ ¨ ^ :::::: "sin argumento, el tiempo de ejecución lo aceptará, el compilador simplemente no puede o es imposible analizarlo. No hay absolutamente ningún control de cordura cuando se trata de selectores.

Supongo que no son compatibles con Objective-C porque tampoco estaban disponibles en Smalltalk. Pero eso tiene una razón diferente a la que cree: no son necesarios. Lo que se necesita es soporte para métodos con 0, 1, 2, 3, ... argumentos. Para cada número de argumentos, ya existe una sintaxis funcional para llamarlos. Agregar cualquier otra sintaxis solo causaría una confusión innecesaria.

Si deseaba selectores sin parámetros de varias palabras, ¿por qué detenerse con una sola palabra adicional? Entonces uno podría preguntar eso

 [axolotl perform selector: Y with object: Y]

también se admite (es decir, que un selector es una secuencia de palabras, algunas con dos puntos y un parámetro, y otras no). Si bien esto hubiera sido posible, supongo que nadie consideró que valiera la pena.