Optionales útil de una manera obvia en un lenguaje de tipo estático, pero me pregunto si también es útil en lenguajes dinámicos. Por lo general, no hay un compilador que te diga "oye, usaste esto Optional<String>como un String", por lo que aún tienes que descubrir tus errores en tiempo de ejecución. Tengo un fondo de escritura estático y desde mi perspectiva no puedo ver el beneficio de un Optionaltipo en un lenguaje dinámico.
Respuestas:
Esa debilidad no es realmente diferente a la de todos los tipos en lenguajes dinámicos. Tienes que ejecutarlo para descubrir qué contiene. Las opciones no son realmente diferentes en ese sentido.
Las opciones son más que una simple anotación estática de que un valor puede o no estar presente. Tienen operaciones asociadas con ellos también. Las cadenas de operaciones mapeadas en las opciones son una característica muy útil, que evita que tenga que verificar si hay fallas después de cada paso en la cadena.
Incluso si solo recuperara el valor de inmediato, todavía haría que el programador verificara por Nothingprimera vez que se ejecutó y falló. Sin una opción, ese pinchazo solo se llevaría a cabo si fuera nullla primera vez que lo ejecutó. Muchas referencias de puntero nulo han esperado obstinadamente hasta que el producto estuvo en el campo.
Puedo hablar por Objective-C.
Dado que los lenguajes de tipo dinámico se enlazan tarde, niles inherente buscar un "opcional" (se representa un no valor con ): si verifica el tipo en tiempo de ejecución, lo verifica nilimplícitamente. Por supuesto, esto es encadenable. Esto también se hace inherentemente.
Para los lenguajes mecanografiados estáticos, este concepto adicional es un beneficio, ya que tienen que tomar la decisión de tipo en tiempo de compilación, una situación que los lenguajes mecanografiados dinámicos nunca tienen.