Che cosa intendeva Alan Kay per "incarico" in The Early History of Smalltalk?

L'idea di base (influenzata da Sketchpad) è che la maggior parte delle variabili / valori sono in dinamiche relazioni con l'altro (mantenute dall'interno dell'oggetto), quindi essere in grado di ripristinare direttamente un valore dall'esterno è pericoloso. Perché (in Smalltalk comunque) c'è almeno un metodo di settaggio richiesto, questo consente la possibilità di un'azione di impostazione esterna essere mediata dal metodo interno per mantenere le interrelazioni desiderate. Ma la maggior parte delle persone che usano i setter li usa semplicemente per simulare assegnazioni dirette alle variabili interiori, e questo viola lo spirito e l'intento del vero OOP.

Ma gli oggetti hanno "linee del mondo" di cambiamenti nel tempo. Questo può essere pensato come una storia di versioni dell'oggetto in cui le relazioni sono in accordo. Non ci sono condizioni di gara in questo schema ... un oggetto è visibile solo quando è stabile e non sta più calcolando. Questo è come un orologio a due fasi in HW. (Idea di Strachey, e in una versione diversa da McCarthy, e influenzata da Lucid.)

Un caro saluto,

Alan Kay

Mi rendo conto che Alan ha già risposto a questa domanda, e quindi potrebbe sembrare che sia inutile rispondere ulteriormente. Tuttavia, Alan non ha risposto a tutte le domande che hai avuto.

In particolare:

Would it be fair to say that opaque, immutable instances are being encouraged here? Or is it simply direct state changes that are discouraged? For example, if I have a BankAccount class, it's OK to have GetBalance, Deposit and Withdraw instance methods/messages; just make sure there isn't a SetBalance instance method/message?

La risposta è che non si sta utilizzando un comportamento di ordine superiore per strutturare il programma. I sistemi di servizi finanziari del mondo reale non dovrebbero avere un metodo di deposito su una classe BankAccount, perché non è affatto come le banche lavoravano prima dell'invenzione dei computer! Quando i bancomat sono stati inventati, hanno dovuto letteralmente automatizzare ciò che un Teller ha fatto in banca. Il ruolo di un Teller sarebbe quello di informare i clienti sullo stato del loro account. Per fare questo, al cliente è consentito interagire con il Teller in pochi modi, come passare un Slip di deposito al Teller.

Attraverso la reificazione diretta di questi oggetti - Teller, Deposit Slip, ecc. - il dominio del problema è strutturato in base ai messaggi trasmessi dalle entità nel sistema.

Un Account in sé svolge un ruolo - l'idea di un Conto significa letteralmente un conto di flussi finanziari in entrata e in uscita in relazione a un Asset, Liability, Income o Expense. Un sistema contabile o contabile, registra, conserva e riproduce questi flussi e indica la posizione finanziaria dell'account in un determinato momento. Il rapporto più recente del Teller può essere pensato come "in questo momento", ma non proprio: è davvero la posizione finanziaria descritta dal Contabile in un determinato momento. Ha solo l'illusione di essere "in questo momento" quando vai in banca, perché generalmente sei l'unico autorizzato ad effettuare pagamenti. Questo era particolarmente vero 100 anni fa, ma oggi molte persone hanno automatizzato i pagamenti e l'account può cambiare mentre si è fisicamente in banca con un Balance Slip - perché il Balance Slip ti dice solo del momento in cui è stato timestamp .

Perché è così importante? Bene, chiediti cosa deve essere fatto per registrare una transazione:

Il Cliente ha il proprio registro di controllo interno di tutto ciò che ha fatto, incluse le ricevute dalla Banca. Allo stesso modo, la Banca conserva il proprio registro di controllo interno di tutto ciò che ha fatto. La sempre della banca contabilità a partita doppia , nel senso che registrano le transazioni nella contabilità generale e stato patrimoniale. Ciò consente alla Banca di eseguire riconciliazione e assicurarsi che non vi siano voci spurie quando chiudono i libri per un dato periodo finanziario (giornaliero, settimanale, mensile, trimestrale, annuale, biennale, qualunque) . Ciò suggerisce anche che il record di ciò che viene registrato dovrebbe essere idempotente. Significa, se dovessimo scrivere un programma per elencare tutte le transazioni univoche, potremmo farlo anche se nel nostro registro di controllo interno fossero presenti doppi duplicati, perché abbiamo incorporato identificativi di transazione identi- ficativi nei messaggi di registrazione.

Data la possibilità per i pagamenti automatici di addebitare e accreditare sul tuo conto, sembra logico che l'Accountant possa anche fare previsioni per te. Questa è stata la realizzazione dell'impatto che i computer potrebbero avere sui sistemi di contabilità. Di conseguenza, qualcuno ha inventato uno schema di sistema contabile chiamato Risorse-Eventi-Agenti che era più in linea con non solo guardando in passato, ma anche guardando al futuro e stimando i flussi di cassa con una granularità più fine di prima. Essenzialmente, la REA è solo più metadata dei sistemi di contabilità classica, consentendo una migliore segnalazione e analisi di business. Ad esempio, l'analisi della "catena del valore" e l'analisi della "supply chain" non sono cose facili da fare con la contabilità classica.

Allo stesso modo, Agoric Computing o Smart Contracts portano idee dai meccanismi del mercato al computing. È importante che quando fornisci un Slip di deposito fornisci anche un assegno o un borsellino da depositare. Poiché c'è un tempo di attesa tra la ricezione del controllo e l'accesso al conto, è necessario un modo sicuro per gestire la valuta. A quanto pare, le funzionalità degli oggetti sono un modo naturale per ottenere valuta sicura distribuita. Possono essere utilizzati per garantire che Alice non imbrogli Bob ritirando tutti i suoi fondi dopo aver scritto a Bob quell'assegno.