En este documento, se muestran formas de usar las verificaciones de conexión.
Ejemplos de valores
Cuando defines verificaciones de conexión para entradas y salidas, por lo general, debes considerar que las verificaciones representan tipos.
Las verificaciones de entradas deben incluir todos los "tipos" que aceptan, y las verificaciones de salidas deben incluir exactamente lo que "muestran".
Acepta un solo tipo
En el caso más básico en el que deseas crear un bloque que “acepte” o “devuelva” un tipo, debes incluir ese tipo en la verificación de conexión.
Acepta varios tipos
Para crear un bloque que “acepte” varios tipos, debes incluir todos los tipos aceptados en la verificación de conexión de la entrada.
Por convención, si un resultado se puede aceptar a veces en varias situaciones (p.ej., si permites que los números se usen a veces como cadenas), el resultado debe ser más restrictivo y las entradas deben ser más permisivas. Esta convención se asegura de que las salidas no se conecten donde no son compatibles.
Aceptar cualquier tipo
Para crear un bloque que “acepte” cualquier tipo, debes configurar la verificación de conexión de la entrada en null.
Subtipos de devoluciones
Para crear un bloque que “devuelva” un subtipo, debes incluir el tipo y el supertipo en la verificación de conexión de la salida.
En el caso de los subtipos, está bien tener varias verificaciones en una verificación de salida, ya que el bloque siempre “muestra” ambos tipos.
Cómo mostrar tipos con parámetros
Para crear un bloque que “devuelva” un tipo parametrizado, debes incluir la versión parametrizada y la no parametrizada en la verificación de conexión de la salida.
Según la rigidez que quieras que tenga tu lenguaje de bloqueo, también puedes incluir las variaciones del tipo.
Al igual que con los subtipos, en este caso, está bien tener varias verificaciones en una verificación de salida, ya que el bloque siempre “muestra” ambos tipos.
Ejemplos de pila o sentencia
Existen algunas formas comunes en las que los desarrolladores definen verificaciones para las conexiones anteriores y siguientes. Por lo general, se considera que restringen el orden de los bloques.
Las siguientes conexiones deben incluir qué bloques deben seguir al actual, y las conexiones anteriores incluyen lo que "es" el bloque actual.
Mantén los bloques en orden
Para crear un conjunto de bloques que se conecten en un orden definido, debes incluir qué bloques deben seguir al actual en la próxima verificación de conexión y cuál es el bloque actual en la verificación de conexión anterior.
Permite muchos bloques intermedios
Para crear un conjunto de bloques ordenados que permitan muchos bloques intermedios, debes incluir al menos una entrada de la verificación de conexión anterior del bloque intermedio en la siguiente verificación de conexión del bloque intermedio. Esto permite que el bloque se repita.
No permitir bloques intermedios
Para crear un conjunto de bloques ordenados en los que los bloques del medio sean opcionales, debes incluir al menos una entrada de la verificación de conexión anterior del bloque del medio y de la verificación de conexión anterior del último bloque en la siguiente verificación de conexión del primer bloque. Esto permite que al primer bloque le siga un bloque medio o un último bloque.
Pilas de uno o el otro
Para crear un bloque al que solo puedan seguirle bloques de un grupo o de otro (y no ambos), debes hacer lo siguiente:
Debes incluir al menos una entrada de las verificaciones de conexión anteriores de ambos grupos en la siguiente verificación de conexión del primer bloque.
Debes definir las próximas verificaciones de conexión de los grupos para que solo incluyan valores que se encuentren en sus verificaciones de conexión anteriores (de modo que solo puedan seguirlos bloques del mismo grupo).
