Opened 14 years ago
Last modified 14 years ago
#1070 new task
Conjuntos versus Vectores — at Version 1
| Reported by: | Víctor de Buen Remiro | Owned by: | Víctor de Buen Remiro |
|---|---|---|---|
| Priority: | low | Milestone: | Mantainance |
| Component: | SetAlgebra | Version: | |
| Severity: | minor | Keywords: | |
| Cc: |
Description (last modified by )
Los conjuntos en TOL representados por el tipo "Set" son internamente un array de punteros a objetos TOL con algo más de overhead para el manejo de Struct, NameBlock y otros temas.
Esta representación exhaustiva es muy flexible y potente pero unida a la gran cantidad de información adjunta a todo objeto TOL produce un gran aumento del tamaño de la memoria cuando se manejan conjuntos grandes.
Para ciertos tipos de conjuntos que se utilizan muy a menudo podría pensarse en un método de representación interna más eficiente. Por ejemplo, un conjunto que sólo tuviera números sería mucho más eficaz almacenarlo como un vector de elementos de tipo double. No existiría un objeto TOL para cada elemento sino que sólo cuando se accediera al mismo se crearía el objeto Real con el valor correspondiente.
Evidentemente esto tiene un precio, pues no sería posible acceder por nombre a un conjunto como éste, ni tampoco podría añadírsele con Append algo que no fuera un número.
En lugar de número podría albergar textos, fechas, matrices o cualquier tipo TOL no abstracto, pero nunca podría albergar una serie temporal infinita, una función, un conjunto ni un NameBlock. Estos tipos abstractos quizás se podrían almacenar como expresiones evaluables.
También se podría hacer un almacenamiento especial bastante eficaz para conjuntos, estructurados o no, cuyos campos sean todos no abstractos y para vectores de los mismos, es decir, las típicas tablas que se almacenan en archivos BST o bases de datos.
Incluso cabría la posibilidad de asignar modos de almacenamiento virtual de forma que los datos no residieran físicamente en memoria sino en archivos en disco o bases de datos, aunque esto supondría que los objetos sirvieran únicamente para lectura secuencial.
Tratar de extender el actual tipo Set a estos conceptos tal vez resultase demasiado complicado debido a las restricciones de las operaciones realizables, por lo que quizás sería más sensato crear un nuevo tipo Array que podría albergar sólo elementos de tipos no abstractos incluido el propio Array
Este nuevo tipo tendría una enorme utilidad como puente para el almacenamiento masivo de información en archivos de texto, bases de datos y OIS.
También podría ser la base de una nueva forma de serialización orientada al transporte de información entre aplicaciones TOL remotas.
