hola, esta es una sugerencia para cualquiera que quiera hacer una aportación a bennu.
se me ocurre que sería buena idea tener un programa en c (un exe o su equivalente) al que le pasaras la ruta de tu prg principal y te generara el bgdc.imp con los import necesarios. para su funcionamiento se podría valer del moddesc de splinter, al menos de la salida (el txt con todas las funciones de bennu) para, a partir de ahí, generar su salida .
este exe se podría invocar antes de compilar para que dejara a un lado del prg principal el bgdc.imp y de esta forma se ahorran los imports para las personas que encuentran complicado el tema. posteriormente se podría compilar e interpretar los códigos.
este programa se podría colocar en nuestros ides para lanzarlo antes de la compilación o con algún botón en especial
es solo una sugerencia. si alguien se anima sería bueno.
saludos.
La verdad es que me parece muy buena idea. No hace falta escribirlo en C, en Bennu también se podría hacer.
Karma para el que ponga el código ;D
Yo esque no entiendo el problema de tener que poner los imports.
He programado en C, en Java, en Visual Basic, en C# y en Cobol. Y en todos hay que poner imports (en Cobol, la mayor parte de las veces, no, pero a veces sí). No veo el problema.
Yo me acostumbré a poner los imports, pero para los que no quieren andar buscando a que módulo pertenece esa función x...sería buena idea que esté implementado pero desde el compilador mismo, creo que sería lo más limpio...por ejemplo tener un "bgdc.exe" y un "bgdce.exe" ("e" de easy=fácil) uno que es el de siempre y el otro para el que no quiere poner los imports...eso utópicamente hablando jajajaj! Saludos!
y como resolves el conflicto de modulos por ejemplo, el mod_math y el mod_mathi?
Bueno, eso que decís seria un caso (capaz que hay mas) en el que se rompería la norma y ya no sería viable hacer que el compilador detecte funciones con módulos...Remarco que dije "utópicamente hablando" ;) supuse de entrada que sería complicado... ;)
Quote from: SplinterGU on November 30, 2010, 12:09:06 AM
y como resolves el conflicto de modulos por ejemplo, el mod_math y el mod_mathi?
ahmm...
ok. en este caso pondría la mod_math y un mensaje hacia consola de que hay dos módulos con las mismas funciones y que se usará el primero (que es el más común y el que por orden alfabético va primero).
esta sería una opción viable en este caso, ya que la mayoría de las veces nos referimos a la math, exceptuando en los ports (tengo entendido).
Por supuesto, la idea de agregar los import, como dice yawin, no es ni difícil ni tardado y es común en casi todos los lenguajes que conozco.
Pd. mi comentario es en el caso de un programa aparte al compilador. en el caso del propio compilador no me atrevo a sugerir nada ya que algo oficial es de mayor cuidado
Hombre, se puede crear un entorno gráfico que, en caso de duda sobre qué librería usar, te de las posibles opciones antes de seguir con el proceso. El problema vendría de la mano de las variables predefinidas, pues hay unas cinco que se repiten en diversos módulos, aunque se pueden dejar para el final, a la espera de que la decisión de los módulos por sus funciones resuelva este dilema.
Es más, se podrían añadir directorios personales para las librerías no oficiales.
Yo es que siempre tengo problemas en cuanto meto la palabra FRAME: esto llama al blitter y a las diversas librerías gráficas, y casi nunca consigo resolver las dependencias porque falta una lib* y no hay mensaje de error que ayude a localizarla (y en ocasiones puede pasar con una mod*). Siempre me atasco en el mismo sítio y acabo usando un bgdc.import genérico.