Skip to content

Instantly share code, notes, and snippets.

@josejuan
Created March 22, 2014 18:31
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save josejuan/9712020 to your computer and use it in GitHub Desktop.
Save josejuan/9712020 to your computer and use it in GitHub Desktop.
_"es generación Lazy"_
tienes razón y quizás la he obviado injustamente, es una buena herramienta, pero piensa
por ejemplo que en C#, tú puedes escribir igualmente lo siguiente:
{{
var ApiGit = new JsonProvider<Repo>("http...");
var repo = ApiGit.Load("https://api.github.com/repos/"+user+"/"+repoName);
var gIndex = 3 * repo.Forks + repo.StargazersCount + repo.WatchersCount;
}}
Entonces, VS te dará errores de tipo, pero *si tienes en background el "generador de wrappers"*
(y que seguro puede integrarse como plugin en el analizador de VS si quieres hacerlo bien), tras
generarse la clase automáticamente (al tipo Repo generado también al vuelo), ya tienes los "type
providers" de F#.
En el artículo que te he apuntado, ya comentaba (en el 2008) que ASP ya hacía eso precisamente
(mucho antes de ese 2008) ¡los type providers! cuando creabas un objeto COM como (transcribo):
{{
' Esto es Visual Basic Script en un archivo ASP
Dim fso
Set fso = Server.CreateObject("Scripting.FileSystemObject")
' Aquí, el IDE de Interdev reconoce en tiempo de programación
' los miembros del objeto fso mostrándolos automáticamente
' mediante IntelliSense:
fso.DeleteFile "..."
...
}}
Los type providers fueron introducidos en F# 3.0, entorno al 2012, 4 años más tarde que yo
ya sugiriera esa estrategia para los shaders (nada especial, sólo para mostrar que es algo
que puede hacerse común y que ya sea hacía antes en ASP).
Que los type providers *son una buena herramienta* es obvio y está ya disponible para poder
usarla, pero únicamente en el sentido de liberar boilerplate al programador (¡que no es poco!).
En el otro sentido, esa solución (type providers) queda (elegantemente) entre la de definir
el tipo explícitamente (ej. la de haskell) y las totalmente dinámicas (ej. la de jquery).
Que mis críticas o puntualizaciones no quiten valor a la solución, que está *muy bien*,
sólo son valoraciones de las diferentes estrategias.
Por ejemplo, type providers para XSD es una de las cosas que voy a mirar, ahí hay mucho
trabajo que probablemente pueda reducirse (aunque desgraciadamente cn frecuencia debo
ajustar manualmente los wrappers porque los XSD remotos son...).
(¿Has leído mi mail? :D :D)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment