Tres extensiones reactivas zen

" Extensiones reactivas " es más que un marco. Al menos porque hay una implementación casi idéntica (ajustada para las características específicas del lenguaje y las prácticas de optimización correspondientes) para cada YP popular. Yesenin afirma que "lo grande se ve a distancia". En esta nota, me retiraré a diferentes "distancias" y describiré lo que veo.

Zen primero

Veo una versión push de la implementación clásica de Iterator 'a GoF. Ya escribí sobre esto, por lo tanto, sin detalles.


A esta distancia, la diferencia entre los sistemas push y pull es claramente visible. Después de tal inspiración, cada git push y git pull causa asombro casi reverente. Empiezas a hurgar en el código y a hacer preguntas sagradas sobre los duales.

Segundo zen

"Algo continúa" (próximo método), "algo terminó" (método completado), "todo salió mal" (método de error): tres declaraciones que pueden describir cualquier proceso que se desarrolle con el tiempo. Además, es fácil abstraerse del tiempo físico, reemplazándolo con una "secuencia de estados" (en la cual el sistema se encuentra). Rx le permite reducir una amplia variedad de algoritmos a una sola interfaz (en el sentido de "acuerdo" del programador con otros programadores y, lo que es más importante, con la máquina), sin imponer ninguna restricción en la expresividad (el número de estados posibles) o en (opcional: sincrónico , asíncrona o multiproceso).

La conclusión más importante se deduce de esto: un rx es un proceso. Y si un proceso complejo consta de n subprocesos, entonces ... un rx de "orden superior", que controla el funcionamiento de n rx "primer orden". Por analogía con funciones de orden superior .

Zen tercero

¿Por analogía con las funciones? Sí, características. La última y más poderosa idea es que el rx es solo la decoración de una función: programática, no matemática: esta última vive fuera del tiempo; una función regular es capaz de devolver un resultado; solo una vez Y luego (resultado); - Esta es una versión "reutilizable" de devolución. De ahí la conclusión más importante: todo lo que se puede hacer con funciones OOP matemáticas (puras) y ordinarias (incluyendo currículum , composición y mucho más, a lo que no se dedica este ensayo) se puede hacer con rx. Las funciones son de bloqueo y asíncronas: también rx. Las funciones pueden devolver funciones: rx también. Las funciones pueden ser recursivas: rx también. Los cálculos de funciones se pueden almacenar en caché: también en rx.
Es curioso que en esta etapa de comprensión involuntariamente regrese a ... la programación funcional. No por el bien de la declaratoria, no por el bien de la inmunidad: estos son todos los bonos (opcionales). En lo "funcional" porque se ve obligado a pensar en términos de funciones y sus composiciones; y de acuerdo con la ley inmutable "un rx es un proceso", sus funciones (no clases, clases abstractas, interfaces o cualquier otra cosa) se convierten en el "punto de partida" en el diseño.

Lo tengo todo