ugrás a tartalomhoz

Mit értett ez alatt Alan Kay?

inf3rno · Szep. 22. (P), 14.15
Smalltalk is not only its syntax or the class library, it is not even about classes. I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is “messaging” … The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet – to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas. If you focus on just messaging – and realize that a good metasystem can late bind the various 2nd level architectures used in objects – then much of the language-, UI-, and OS based discussions on this thread are really quite moot.


Egész pontosan a The big idea is “messaging” rész, az ami nagyon homályos. Próbáltam utánajárni, sokan kérdezték Alan Kay-t erről, de mindig ködösített, és sosem mutatott egyetlen példát sem, hogy szerinte hogyan kellene egy oo nyelvet helyesen használni. Van valakinek bármi ötlete?
 
1

Actor model

Poetro · Szep. 22. (P), 15.02
Szerintem az Actor model-re gondolt, mikor nem az egyes objektumok a lényegesek, mivel a belső állapotukat szabadon állíthatják, hanem hogy hogyan kommunikálnak egymással: üzenetekkel.
Emlékszem, mikor egyetemen a Smalltalk-ról tanultunk, akkor ismerkedtünk meg ezzel is. Bár valószínűleg az Erlang tartalmazza a legjobb implementációt. De természetesen JavaScript-ben is megvalósítható.
2

Lehet, hogy tényleg ilyesmire

inf3rno · Szep. 22. (P), 16.07
Lehet, hogy tényleg ilyesmire gondolhatott, de ez csak indirekt bizonyítéknak tűnik.

Próbálkoztam js-ben ilyesmit összerakni a callback hell kezelésére régebben, de baromi körülményes mindent ilyen elvek mentén programozni. A példák működtek, de nem volt jó rájuk nézni. A fő gond ezzel a megközelítéssel, hogy az actorok között nincs osztály szinten függőség, és emiatt nem alakulnak ki az osztály deklarációknál egyértelműen absztrakciós szintek. Helyette ezekről a függőségekről csak a példányok tudnak, vagy ha pub/sub-ot alkalmazol, akkor még azok sem. Ez rendkívül nagy rugalmasságot ad a futó kódnak, de nagyon nehezen karbantartható, debuggolható lesz a végeredmény, és nehéz az osztályokat kialakítani már kis méretű projektnél is. Esetleg találtak ezekre a problémákra valami megoldást az actor model népszerűsítői?

Esetleg én értettem félre valamit, és ez csak egy pattern, amit néha használnak néha nem? Ha így van, akkor nem tudom mivel ad többet egy pub/sub-nál.
3

Példa

Hidvégi Gábor · Szep. 22. (P), 17.20
Pedig ír példát is: az internet. Van egy kliensed, ami a szervernek küld egy üzenetet: GET index.html, és kap cserébe egy HTML dokumentumot. A kommunikáció szabványos, az viszont rejtett, hogy belül mi is történik.

OOP-ben ez annak felel meg, amikor meghívod egy objektum metódusát, az meg visszaad valamilyen értéket.
4

Ez ugyanúgy igaz lenne sima

inf3rno · Szep. 22. (P), 18.22
Ez ugyanúgy igaz lenne sima függvényekre is, pl egy getIndex() függvényre. Szóval ha csak ennyiről van szó, akkor nem nyújt valami sok újat az OOP. Persze ezt a magyarázatot sem zárhatjuk ki az actor model mellett.
9

Más

Hidvégi Gábor · Szep. 25. (H), 09.24
Itt csak annyiról van szó, hogy Alan Kay egészen mást értett objektum-orientáltságon, mint ami mára lett belőle, de ezt is leírja az általad idézett szövegben.
10

Jól látod. Pont az hiányzik,

inf3rno · Szep. 26. (K), 00.15
Jól látod. Pont az hiányzik, hogy pontosan mit szeretett volna, és hogy azzal a módszerrel hogy nézne ki egy példa alkalmazás.
5

Messaging = decoupling

BlaZe · Szep. 22. (P), 21.54
Az OO alap koncepciója szerint az objektumok zártak, és üzenetekkel lehet velük kommunikálni. Az egyetlen amit tudsz egy objektumról, hogy hogyan érd el és hogy milyen üzenetekkel lehet megszólítani. Ez az alapvető lényege a decouplingnak. Kicsiben (method invocation), nagyban (klasszikus messaging, pub/sub, request/response, message queue etc) egyaránt.

A különbség a függvény és a metódus hívás között az, hogy függvény esetében direkt vezérlésátadás történik, míg metódushívás esetén az üzenetet (metódushívás) fel kell oldani, hogy kiderüljön milyen kódnak kell lefusson (dynamic dispatching). Ebből következik maga a polimorfizmus: bármi lehet az objektum, csak az ismert üzenetformátum a fix. Az üzenet feldolgozója lehet akár egy szimpla lokális implementáció, több lokális implementáció, vagy akár remote implementáció (RPC, remote EJB, web service, actor etc). Lehet bonyolítani time independencyvel is a dolgot (az objektum nincs is online az üzenet küldésekor) stb. Ha nem a mainstream nyelvekben használatos implementációhoz ragaszkodunk, mint objektum, hanem egy absztrakt "valaminek" definiáljuk, ami üzenetekre hajt végre műveleteket, akkor könnyebb megérteni a fentit (szerintem).

Valóban a messaging az alapja mindennek. A concurrency alapja is az, legyen szó akár elosztott rendszerekről, akár többszálú programokról. A CPU magok is üzenetküldéssel kommunikálnak egymással, a cache subsystemmel, azok is belül stb.

A messaging maga a decoupling, kb ez a lényeg.
6

Köszi! Akkor mégiscsak

inf3rno · Szep. 22. (P), 23.59
Köszi! Akkor mégiscsak ilyesmire gondolt, legalábbis már ketten írtátok. Számomra a dependency injecton nem fér bele ebbe az üzenetküldéses gondolatmenetbe.
7

Szerintem nem is kell, hogy

smokey · Szep. 23. (Szo), 13.18
Szerintem nem is kell, hogy beleférjen. Az üzenet küldés publikus csatornákon, vagyis interfészeken keresztül valósul meg. Ha interfészekre építed az egész alkalmazásod, akkor láthatóvá válnak a csatornák. Az viszont egy másik kérdés - és a megválaszolása nem is kell, hogy interfész szinen látszódjon -, hogy ezt DI-al, vagy anélkül valósítod meg; és az is rejtve maradhat, hogy mi történik az egységeken belül - blackbox.

Az internet példája szerintem jó. Ha pl vizsgálsz egy REST API-t, vagy bármit, akkor adottak a bemenetek, adott a kimenet formátuma, de az, hogy a kimenetet PHP FPM nginx állíja elő, vagy egy NodeJS+Express (vagy hapi, vagy bármi) backend, az eredmény szemponjtából mindegy.
8

Köszi! Teljesen igazad van.

inf3rno · Szep. 23. (Szo), 14.18
Köszi! Teljesen igazad van. Én egyébként egy konkrét régi projektem kontextusában kérdeztem, ami annak idején félbemaradt. Azt hiszem csak hangosan gondolkodtam. Úgy néz ki, hogy a 2-3 évvel ezelőtti problémákat sikerült megoldanom az új információkkal.

Leginkább azzal küzdöttem, hogyha egy actor (szerű) obektumot feldarabolsz egy sok kis actor-ból álló gráfra, akkor azt hogyan tudod úgy bekötni a már meglevő actor gráfba, hogy továbbra is csak egy actor-nak látszódjon és így el tudd rejteni a megvalósítás részleteit. Ez hasonló, mint amikor OOP-ben feldarabolsz egy osztályt, mert túl nagyra nőtt, aztán composition-el és dependency injection-el újra összerakod ugyanazzal a felülettel. Így absztrakciós rétegek alakulnak ki közben. Ugye az eredeti osztály van magasabb szinten, az új osztályok meg alacsonyabb szinteken. Az actor gráfomnál is ugyanilyen rétegeket szerettem volna látni, ami mentén könnyebben megérthető, hogy hogyan működik a kód (akár valamilyen gráf vizualizáción is a realtime futó kód). Most az új infok alapján nagyjából lejött, hogy hogyan kell megközelíteni ezt a problémát, illetve, hogy az interneten a router a legjobb analógia rá. Azt hiszem sínen vagyok. Mondjuk a projekt már erősen túlhaladott, mióta van async-await, de hobbiból azért befejezem.