¿Qué quiso decir Alan Kay con "asignación" en La historia temprana de Smalltalk?

He estado leyendo The Early History of Smalltalk y hay algunas menciones de "asignación" que me hacen cuestionar mi comprensión de su significado:

Aunque la POO provenía de muchas motivaciones, dos eran centrales. El de gran escala era encontrar un mejor esquema de módulo para sistemas complejos que involucraban la ocultación de detalles, y el de pequeña escala era encontrar una versión más flexible de la asignación y luego tratar de eliminarla por completo.

(de 1960-66 - OOP temprana y otras ideas formativas de los años sesenta , Sección I)

Lo que obtuve de Simula fue que ahora podías reemplazar los enlaces y la asignación por objetivos . Lo último que quería que hiciera cualquier programador es meterse con el estado interno, incluso si se presenta de forma figurada. En cambio, los objetos deben presentarse como sitios de comportamientos de nivel superior más apropiados para su uso como componentes dinámicos . (...) Es lamentable que gran parte de lo que hoy se llama "programación orientada a objetos" es simplemente una programación de estilo antiguo con construcciones más sofisticadas. Muchos programas se cargan con operaciones de "estilo de asignación" que ahora se realizan mediante procedimientos adjuntos más caros.

(del estilo "Orientado a objetos" , Sección IV)

¿Estoy en lo correcto al interpretar que la intención es que los objetos están destinados a ser fachadas y que cualquier método (o "mensaje") cuyo propósito es establecer una variable de instancia en un objeto (es decir, una "asignación") está frustrando el propósito? Esta interpretación parece estar respaldada por dos declaraciones posteriores en la Sección IV:

Cuatro técnicas utilizadas juntas: estado persistente, polimorfismo, creación de instancias y métodos como objetivos para el objeto, representan gran parte del poder. Ninguno de estos requiere que se emplee un "lenguaje orientado a objetos" (ALGOL 68 casi puede recurrir a este estilo) y OOPL simplemente enfoca la mente del diseñador en una dirección fructífera en particular. Sin embargo, hacer la encapsulación correctamente es un compromiso no solo con la abstracción del estado, sino también con la eliminación de metáforas orientadas al estado de la programación.

...y:

Las declaraciones de asignación, incluso las abstractas, expresan objetivos de muy bajo nivel, y se necesitarán más para hacer cualquier cosa. En general, no queremos que el programador esté jugando con el estado, ya sea simulado o no.

¿Sería justo decir que aquí se fomentan instancias opacas e inmutables? ¿O se trata simplemente de cambios directos de estado que se desaconsejan? Por ejemplo, si tengo una BankAccountclase, que está bien tener GetBalance, Deposity Withdrawlos métodos de instancia / mensajes; solo asegúrese de que no haya un SetBalancemétodo / mensaje de instancia?

La idea básica (influenciada por Sketchpad) es que la mayoría de las variables / valores están en relaciones dinámicas entre sí (mantenidas por el interior del objeto), por lo que es peligroso restablecer directamente un valor desde el exterior. Debido a que (en Smalltalk de todos modos) se requiere al menos un método de establecimiento, esto permite la posibilidad de que una acción de configuración externa sea mediada por el método interno para mantener las interrelaciones deseadas. Pero la mayoría de las personas que usan setters simplemente los usan para simular asignaciones directas a variables interiores, y esto viola el espíritu y la intención de OOP real.

Pero los objetos tienen "líneas mundiales" de cambios en el tiempo. Esto puede considerarse como una historia de las versiones del objeto en el que las relaciones están de acuerdo. No hay condiciones de carrera en este esquema ... un objeto solo es visible cuando es estable y ya no se computa. Esto es como un reloj de dos fases en HW. (Idea de Strachey, y de una manera diferente de McCarthy, e influenciada por Lucid.)

Los mejores deseos,

Alan Kay

Me doy cuenta de que Alan ya respondió a esta pregunta, por lo que podría parecer que no tiene sentido responder más. Sin embargo, Alan no respondió todas las preguntas que tenía.

En particular:

¿Sería justo decir que aquí se fomentan instancias opacas e inmutables? ¿O se trata simplemente de cambios directos de estado que se desaconsejan? Por ejemplo, si tengo una clase BankAccount, está bien tener métodos / mensajes de instancia GetBalance, Deposit and Withdraw; solo asegúrese de que no haya un método / mensaje de instancia de SetBalance?

La respuesta aquí es que no está utilizando un comportamiento de orden superior para estructurar su programa. Los sistemas de servicios financieros del mundo real no deberían tener un método de depósito en una clase de BankAccount, ¡porque no es así como funcionaban los bancos antes de la invención de las computadoras! Cuando se inventaron los cajeros automáticos, tuvieron que automatizar literalmente lo que hizo un cajero en el banco. La función de un cajero sería notificar a los clientes sobre el estado de su cuenta. Para hacer esto, el cliente solo puede interactuar con el cajero de algunas maneras, como pasar un comprobante de depósito al cajero.

Al reificar directamente estos objetos (cajero, comprobante de depósito, etc.), el dominio del problema se estructura de acuerdo con los mensajes transmitidos por las entidades del sistema.

Una cuenta en sí misma desempeña un papel: la idea de una cuenta significa literalmente una cuenta de entradas y salidas financieras en relación con un activo, pasivo, ingresos o gastos. Un sistema de contabilidad, o contador, registra, retiene y reproduce estos flujos y le informa la posición financiera de la cuenta en un momento determinado. El informe más reciente del cajero puede considerarse como "en este momento", pero no realmente: es realmente la situación financiera descrita por el contador en un momento dado. Simplemente tiene la ilusión de estar "en este momento" cuando va al banco, porque generalmente usted es el único autorizado para realizar pagos. Esto fue especialmente cierto hace 100 años, pero hoy en día muchas personas tienen pagos automáticos,

¿Porque es esto importante? Bueno, pregúntese qué debe hacerse para registrar una transacción:

El Cliente tiene su propio registro de auditoría interna de todo lo que ha hecho, incluidos los recibos del Banco. Asimismo, el Banco mantiene su propio registro de auditoría interna de todo lo que han hecho. El Banco siempre realiza una contabilidad de doble entrada , lo que significa que registra las transacciones en el Libro mayor y el Balance general. Esto permite al Banco realizar la reconciliación.y asegúrese de que no haya entradas espurias cuando cierren sus libros durante un período financiero determinado (diario, semanal, mensual, trimestral, anual, semestral, lo que sea). Esto también sugiere que el registro de lo que se registra debe ser idempotente. Es decir, si tuviéramos que escribir un programa para enumerar todas las transacciones únicas, podríamos hacerlo incluso si hubiera duplicados espurios en nuestro registro de auditoría interna, porque incorporamos identificadores de transacciones idempotentes en los mensajes de registro.

Dada la capacidad de los pagos automáticos para debitar y acreditar su cuenta, parece tener sentido que el Contador también pueda hacer pronósticos para usted. Esta fue la comprensión del impacto que las computadoras podrían tener en los sistemas de contabilidad. En consecuencia, alguien inventó un esquema de sistema de contabilidad llamado Resources-Events-Agents que estaba más alineado no solo con mirar el pasado, sino también mirar el futuro y estimar los flujos de efectivo con una granularidad más fina que antes. Esencialmente, REA es simplemente más metadatos que los sistemas de contabilidad clásicos, lo que permite mejores informes y análisis de negocios. Por ejemplo, el análisis de la "cadena de valor" y el análisis de la "cadena de suministro" no son cosas fáciles de hacer con la contabilidad clásica.

Del mismo modo, Agoric Computing o Smart Contracts aporta ideas de los mecanismos del mercado a la informática. Es importante que cuando proporcione un comprobante de depósito, también proporcione un cheque o cartera para depositar. Dado que hay un tiempo de espera entre la recepción del Cheque y el ingreso real en su Cuenta, necesita una forma segura de administrar la moneda. Como resultado, las capacidades de los objetos son una forma natural de lograr una moneda segura distribuida. Se pueden usar para asegurarse de que Alice no engañe a Bob al retirar todos sus fondos después de que ella le escribió ese cheque.