Programación reactiva

Los métodos de propagación de datos más comunes son:

• Pull – El consumidor de valor es proactivo , ya que consulta regularmente la fuente observada en busca de valores y reacciona cuando hay un valor relevante disponible. Esta práctica de comprobar periódicamente si hay eventos o cambios de valor se conoce comúnmente como sondeo .
• Push : El consumidor recibe un valor de la fuente cuando este está disponible. Estos valores son autocontenidos; es decir, contienen toda la información necesaria y el consumidor no necesita consultar información adicional.
• Modelo Push-pull : El consumidor de valor recibe una notificación de cambio , que es una breve descripción del cambio, por ejemplo, "algún valor ha cambiado": esta es la parte push . Sin embargo, la notificación no contiene toda la información necesaria (es decir, no contiene los valores reales), por lo que el consumidor necesita consultar la fuente para obtener más información (el valor específico) después de recibir la notificación: esta es la parte pull . Este método se usa comúnmente cuando hay un gran volumen de datos que podrían interesar a los consumidores. Por lo tanto, para reducir el rendimiento y la latencia, solo se envían notificaciones ligeras; luego, aquellos consumidores que necesitan más información la solicitan. Este enfoque también tiene el inconveniente de que la fuente podría verse saturada por muchas solicitudes de más información después de que se envía una notificación.

A nivel de implementación, la reacción a eventos consiste en la propagación a través de la información de un grafo, que caracteriza la existencia de un cambio. En consecuencia, los cálculos afectados por dicho cambio quedan obsoletos y deben marcarse para su reejecución. Estos cálculos suelen caracterizarse por el cierre transitivo del cambio (es decir, el conjunto completo de dependencias transitivas que afecta una fuente) en su fuente asociada. La propagación del cambio puede entonces dar lugar a una actualización del valor de los sumideros del grafo .

La información propagada en un grafo puede consistir en el estado completo de un nodo, es decir, el resultado del cálculo del nodo en cuestión. En estos casos, se ignora la salida anterior del nodo. Otro método implica la propagación delta, es decir, la propagación de cambios incrementales . En este caso, la información se propaga a lo largo de las aristas del grafo, que consisten únicamente en deltas que describen cómo cambió el nodo anterior. Este enfoque es especialmente importante cuando los nodos contienen grandes cantidades de datos de estado , que de otro modo serían costosos de recalcular desde cero.

La propagación delta es esencialmente una optimización que se ha estudiado ampliamente dentro de la disciplina de la computación incremental , cuyo enfoque requiere la satisfacción en tiempo de ejecución que involucra el problema de actualización de vistas . Este problema se caracteriza, de manera notoria, por el uso de entidades de base de datos , que son responsables del mantenimiento de las vistas de datos cambiantes.

Otra optimización común consiste en emplear la acumulación de cambios unarios y la propagación por lotes . Esta solución puede ser más rápida, ya que reduce la comunicación entre los nodos involucrados. Posteriormente, se pueden emplear estrategias de optimización que analicen la naturaleza de los cambios contenidos y realicen las modificaciones correspondientes (por ejemplo, dos cambios en el lote pueden anularse mutuamente y, por lo tanto, simplemente ignorarse). Otro enfoque disponible se describe como propagación de notificaciones de invalidez . Este enfoque hace que los nodos con entradas no válidas soliciten actualizaciones, lo que resulta en la actualización de sus propias salidas.

Existen dos métodos principales para construir un gráfico de dependencias :

1. El grafo de dependencias se mantiene implícitamente dentro de un bucle de eventos . El registro de funciones de devolución de llamada explícitas genera dependencias implícitas. Por lo tanto, la inversión de control , inducida mediante la función de devolución de llamada, se mantiene. Sin embargo, para que las funciones de devolución de llamada sean funcionales (es decir, que devuelvan el valor del estado en lugar del valor de la unidad), es necesario que dichas funciones sean compositivas.
2. Un grafo de dependencias es específico del programa y lo genera un programador. Esto facilita abordar la inversión de control de la función de devolución de llamada de dos maneras: o bien se especifica un grafo explícitamente (normalmente usando un lenguaje específico de dominio (DSL), que puede estar integrado), o bien se define un grafo implícitamente con expresión y generación usando un lenguaje arquetípico eficaz .

Al propagar cambios, es posible elegir órdenes de propagación tales que el valor de una expresión no sea una consecuencia natural del programa fuente. Podemos ilustrar esto fácilmente con un ejemplo. Supongamos que secondses un valor reactivo que cambia cada segundo para representar el tiempo actual (en segundos). Consideremos esta expresión:

t = segundos + 1 g = (t > segundos) 

Como tsiempre debe ser mayor que seconds, esta expresión siempre debería evaluarse como verdadera. Desafortunadamente, esto puede depender del orden de evaluación. Cuando secondscambia, dos expresiones deben actualizarse: seconds + 1y la condicional. Si la primera se evalúa antes que la segunda, entonces esta invariante se cumplirá. Sin embargo, si la condicional se actualiza primero, usando el valor antiguo de ty el nuevo valor de seconds, entonces la expresión se evaluará como falsa. Esto se llama un fallo .

Algunos lenguajes reactivos no presentan fallos y demuestran esta propiedad. Esto se suele lograr ordenando topológicamente las expresiones y actualizando los valores en orden topológico. Sin embargo, esto puede tener implicaciones en el rendimiento, como el retraso en la entrega de valores (debido al orden de propagación). Por lo tanto, en algunos casos, los lenguajes reactivos permiten fallos, y los desarrolladores deben ser conscientes de la posibilidad de que los valores no se correspondan temporalmente con el código fuente del programa, y ​​de que algunas expresiones se evalúen varias veces (por ejemplo, se puede evaluar dos veces: una cuando llega el nuevo valor y otra cuando se actualiza).t > secondssecondst

La ordenación topológica de dependencias depende de que el grafo de dependencias sea un grafo acíclico dirigido (DAG). En la práctica, un programa puede definir un grafo de dependencias con ciclos. Generalmente, los lenguajes de programación reactiva esperan que estos ciclos se rompan colocando algún elemento en una arista de retroceso para permitir que la actualización reactiva finalice. Normalmente, los lenguajes proporcionan un operador como delayel que utiliza el mecanismo de actualización para este propósito, ya que delayimplica que lo que sigue debe evaluarse en el siguiente paso temporal (lo que permite que la evaluación actual finalice).

Los lenguajes reactivos suelen asumir que sus expresiones son puramente funcionales . Esto permite que un mecanismo de actualización elija diferentes órdenes para realizar las actualizaciones, dejando el orden específico sin especificar (lo que posibilita optimizaciones). Sin embargo, cuando un lenguaje reactivo se integra en un lenguaje de programación con estado, los programadores pueden realizar operaciones mutables. Cómo lograr una interacción fluida sigue siendo un problema abierto.

En algunos casos, es posible contar con soluciones parciales basadas en principios. Dos de estas soluciones son:

• Un lenguaje puede ofrecer la noción de "celda mutable". Una celda mutable es aquella de la que el sistema de actualización reactiva tiene conocimiento, de modo que los cambios realizados en ella se propagan al resto del programa reactivo. Esto permite que la parte no reactiva del programa realice una mutación tradicional, al tiempo que permite que el código reactivo conozca y responda a esta actualización, manteniendo así la coherencia de la relación entre los valores del programa. Un ejemplo de lenguaje reactivo que proporciona dicha celda es FrTime. ^{[ 4 ]}
• Las bibliotecas orientadas a objetos debidamente encapsuladas ofrecen una noción de estado encapsulada. En principio, por lo tanto, es posible que dicha biblioteca interactúe sin problemas con la parte reactiva de un lenguaje. Por ejemplo, se pueden instalar funciones de devolución de llamada en los métodos get de la biblioteca orientada a objetos para notificar al motor de actualización reactiva sobre los cambios de estado, y los cambios en el componente reactivo se pueden enviar a la biblioteca orientada a objetos a través de los métodos get. FrTime emplea esta estrategia. ^{[ 5 ]}

En algunos lenguajes reactivos, el grafo de dependencias es estático , es decir, permanece fijo durante la ejecución del programa. En otros lenguajes, el grafo puede ser dinámico , es decir, puede cambiar a medida que se ejecuta el programa. Como ejemplo sencillo, consideremos este ejemplo ilustrativo (donde secondses un valor reactivo):

t = si ((segundos mod 2) == 0): segundos + 1 demás: segundos - 1 fin t + 1 

Cada segundo, el valor de esta expresión cambia a una expresión reactiva diferente, de la cual t + 1depende. Por lo tanto, el gráfico de dependencias se actualiza cada segundo.

Permitir la actualización dinámica de dependencias proporciona una gran capacidad expresiva (por ejemplo, las dependencias dinámicas son habituales en los programas con interfaz gráfica de usuario [GUI]). Sin embargo, el motor de actualización reactiva debe decidir si reconstruir las expresiones cada vez o mantener el nodo de una expresión construido pero inactivo; en este último caso, debe asegurarse de que no participen en el cálculo cuando no deban estar activos.

La programación reactiva presenta similitudes principales con el patrón observador, comúnmente utilizado en la programación orientada a objetos . Sin embargo, integrar los conceptos de flujo de datos en el lenguaje de programación facilitaría su expresión y, por lo tanto, podría aumentar la granularidad del grafo de flujo de datos. Por ejemplo, el patrón observador suele describir flujos de datos entre objetos o clases completas, mientras que la programación reactiva orientada a objetos podría centrarse en los miembros de dichos objetos o clases.