scala - programming - ¿Cómo manejar las dos señales dependiendo una de la otra?
rx react (4)
Compruebe su conocimiento MVC . La vista no actualiza el modelo, por lo que no le enviará señales. El controlador actualiza el modelo. Para un convertidor C / F, tendría dos controladores (uno para el control F, activado para el control C). Ambos controladores enviarían señales a un solo modelo (que almacena la única temperatura real, Kelvin, en un formato sin pérdidas ). El modelo envía señales a dos vistas separadas (una para vista C, otra para vista F). No hay ciclos.
Según la respuesta de @ pagoda_5b, diría que es probable que se le permita tener ciclos (7.6 debería manejarlo, a costa del rendimiento), pero debe garantizar que no haya una regresión infinita. Por ejemplo, podría hacer que los controladores también reciban señales del modelo, siempre y cuando garantice que la recepción de dicha señal nunca hizo que se enviara una señal al modelo.
Creo que lo anterior es una buena descripción, pero usa la palabra "señal" en un estilo que no es FRP. "Señales" en lo anterior son realmente mensajes. Si la descripción en 7.1 es correcta y completa, los bucles en el gráfico de señales siempre causarán un retroceso infinito ya que el procesamiento de los dependientes de un nodo causaría que el nodo sea procesado y viceversa, ad inf.
Como dijo @Matt Carkci, hay marcos de FRP que permiten bucles, al menos hasta cierto punto. No se basarán en el empuje, utilizarán la no rigidez de manera interesante, impondrán la monotonicidad o introducirán retrasos "artificiales" para que cuando se amplíe el gráfico de señales en la dimensión temporal (convirtiéndolo en un gráfico de valores) los ciclos desaparezcan.
Leí Deprecating the Observer Pattern with Scala.React y me pareció muy interesante la programación reactiva.
Pero hay un punto que no puedo entender: el autor describió las señales como los nodos en un DAG (Gráfico acíclico dirigido). Entonces, ¿qué sucede si tiene dos señales (o fuentes de eventos, o modelos, w / e) dependiendo de cada una? es decir, el ''enlace bidireccional'', como un modelo y una vista en la programación web de front-end.
A veces es simplemente inevitable porque el usuario puede cambiar la vista, y el back-end (solicitud asíncrona, por ejemplo) puede cambiar el modelo, y usted espera que el otro lado refleje el cambio de inmediato.
Después de escanear el papel, no puedo encontrar donde mencionan que debe ser acíclico. No hay nada que le impida crear gráficos cíclicos en el flujo de datos / programación reactiva. Los gráficos acíclicos solo le permiten crear un flujo de datos de tubería (por ejemplo, tuberías de línea de comando de Unix).
La retroalimentación y los ciclos son un mecanismo muy poderoso en el flujo de datos. Sin ellos, estás restringido a los tipos de programas que puedes crear. Eche un vistazo a la programación basada en flujo: redes tipo bucle .
Editar después del segundo post por pagoda_5b
Una declaración en el periódico me hizo tomar nota ...
Para los gráficos ordenados correctamente, este proceso avanza monótonamente a niveles mayores, lo que garantiza la consistencia de los datos, es decir, la ausencia de fallos.
Para mí, eso dice que los bucles no están permitidos dentro del marco Scala.React. Un ciclo entre dos nodos parece hacer que el sistema intente continuamente elevar el nivel de ambos nodos para siempre.
Pero eso no significa que tenga que codificar los bucles dentro de su marco. Podría ser posible tener una ruta desde el elemento que desea observar y luego otra ruta separada hacia la GUI.
Para mí, siempre parece que se pone demasiado énfasis en que un sistema de programación complete y dé una respuesta. Los bucles hacen que sea difícil determinar cuándo terminar. Las bibliotecas que usan el término "reactivo" tienden a suscribirse a este proceso de pensamiento. Pero eso es solo el resultado de la arquitectura de computadoras de Von Neumann ... un enfoque de resolver una ecuación y devolver la respuesta. Las bibliotecas que se alejan de los bucles parecen estar preocupadas por la finalización del programa.
El flujo de datos no requiere que un programa tenga una respuesta correcta o que alguna vez termine. La respuesta es la respuesta en este momento debido a las entradas en este momento. Se esperan comentarios y bucles si no se requieren. Un sistema de flujo de datos es básicamente un gran bucle que constantemente pasa datos entre nodos. Para terminarlo, simplemente detente.
El flujo de datos no tiene que ser tan complicado. Es solo una forma muy diferente de pensar acerca de la programación. Le sugiero que consulte el libro "Programación basada en flujo" de J. Paul Morison para obtener una versión de flujo de datos probada en el campo o mi libro (una vez que esté listo).
Las dependencias de bucle en un lenguaje de programación reactivo se pueden manejar con una variedad de semánticas. El que parece haber sido elegido en scala.React es el de lenguajes reactivos sincrónicos y específicamente el de Esterel. Puede tener una buena explicación de esta semántica y sus alternativas en el documento "Los lenguajes sincrónicos 12 años después" por Benveniste, A.; Caspi, P.; Edwards, SA; Halbwachs, N.; Le Guernic, P.; de Simone, R. y disponible en http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=1173191&tag=1 o http://virtualhost.cs.columbia.edu/~sedwards/papers/benveniste2003synchronous.pdf .
Respondiendo a @Matt Carkci aquí, porque un comentario no sería suficiente
En la sección de papel 7.1. Propagación de cambios que tiene.
Nuestra implementación de propagación de cambios utiliza un enfoque basado en empuje basado en un gráfico de dependencia ordenado topológicamente . Cuando comienza un giro de propagación, el propagador coloca todos los nodos que se han invalidado desde el último giro en una cola de prioridad que se clasifica según el orden topológico, brevemente a nivel , de los nodos. El propagador pone en cola el nodo en el nivel más bajo y lo valida, cambiando potencialmente su estado y colocando sus nodos dependientes, que están en niveles mayores, en la cola. El propagador repite este paso hasta que la cola está vacía, siempre realizando un seguimiento del nivel actual, lo que se vuelve importante para los desajustes de nivel a continuación. Para los gráficos ordenados correctamente, este proceso avanza monótonamente a niveles mayores, lo que garantiza la consistencia de los datos, es decir, la ausencia de fallos.
y más tarde en la sección 7.6 desajuste de nivel
Por lo tanto, debemos prepararnos para que un nodo opaco n acceda a otro nodo que se encuentre en un nivel topológico superior. Cada nodo que se lee durante la evaluación de n , primero verifica si el nivel de propagación actual que mantiene el propagador es mayor que el nivel del nodo. Si es así, proceda como de costumbre, de lo contrario, lanza una excepción de falta de coincidencia de nivel que contiene una referencia a sí misma, que se captura solo en el bucle de propagación principal. El propagador luego eleva n cambiando primero su nivel a un nivel por encima del nodo que arrojó la excepción, reinsertando n en la cola de propagación (ya que su nivel ha cambiado) para una evaluación posterior en el mismo turno y luego elevando de forma transitiva todos los n dependientes
Si bien no hay ninguna mención sobre ninguna restricción topológica (cíclica contra acíclica), algo no está claro. (al menos a mi)
Primero surge la pregunta de cómo se define el orden topológico.
Y luego, la implementación sugiere que los nodos mutuamente dependientes se integrarán para siempre en la evaluación a través del mecanismo de excepción explicado anteriormente.
¿Qué piensas?