Mit értett ez alatt Alan Kay?
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?
Actor model
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ó.
Lehet, hogy tényleg ilyesmire
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.
Példa
OOP-ben ez annak felel meg, amikor meghívod egy objektum metódusát, az meg visszaad valamilyen értéket.
Ez ugyanúgy igaz lenne sima
Más
Jól látod. Pont az hiányzik,
Messaging = decoupling
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.
Köszi! Akkor mégiscsak
Szerintem nem is kell, hogy
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.
Köszi! Teljesen igazad van.
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.