Need to define class common members

[pgea@…]

Cada instancia de una clase crea una copia de cada uno de sus miembros. Sería conveniente evitar esto, ya que puede incrementar innecesariamente el tamaño en memoria y dificultar el tratamiento masivo de estas instancias.
Véase el archivo .tol adjunto.

[Víctor de Buen Remiro]

En los NameBlock que no son instancias de nada no veo porqué los objetos tengan que distinguir funciones del resto de variables, aunque también puede ser discutible, pero en el caso de las instancias es evidente que resultará más eficiente hacer referencias a una única función, y no se pierde ninguna capacidad pues no es razonable crear una estructura de clases con métodos heredados para que luego cada instancia tenga la capacidad de cambiar los comportamientos de esos métodos. Eso no aporta potencia y resta recursos, así que sobra.

Por lo tanto, en principio parece que tiene sentido esta petición, aunque existen algunas dificultades y dudas al respecto.

Por un lado las instancias se pueden crear bien con la declaración estándar <nombre_clase> <nombre_objeto> = [[ <lista_miembros_y_métodos> ]]; , o bien mediante copia con el operador Copy.

Con respecto al método de declaración estándar, las clases actualmente sólo almacenan el árbol sintáctico de cada miembro y método, y son las instancias las que evalúan dicho árbol. La evaluación de los miembros debe ser realizada así pues sólo en la instancia se garantiza que todos ellos estén definidos y sean distintos para cada una. Los métodos en cambio sí se podrían preevaluar y almacenar en las propias clases y ser simplemente referenciados en las instancias.

Con respecto al método de declaración con Copy, hasta hace poco (ver ticket #712) no existía la copia de NameBlock y por ende tampoco de instancias. Al resolver ese ticket los NameBlock copian todos sus elementos independientemente de cuál sea su tipo, y hay que recordar que en TOL las funciones no dejan de ser variables de tipo Code, por lo que también se copian.

En principio sería facil de distinguir en el código interno C++ cuando el NameBlock es una instancia para no realizar la copia de sus métodos sino crear tan solo referencias internas.

Por otra parte hay que tener en cuenta otra cosa, y es que una clase además de métodos puede tener miembros de tipo Code para almacenar referencias a funciones cualesquiera, no necesariamente métodos, y en este caso habría que duplicar el objeto en la ejecución de Copy para evitar efectos secundarios en la instancia origen de la copia.

Surgen por lo tanto varias tareas que se irán haciendo cuanto antes.

[Víctor de Buen Remiro]

(In [1228]) Class instances doesn't store the Class methods that will be stored as just one copy in the Class handler.
Fixed #722

[Víctor de Buen Remiro]

(In [1229]) Class instances doesn't store the Class methods that will be stored as just one copy in the Class handler.
Fixed #722

[Víctor de Buen Remiro]

Por fin ha sido posible hacer que sean las clases y no las isntancias las que contengan los métodos. Ya está resuelto en el trunk y pronto estará disponible en la release binaria de windows.

[pgea@…]

Entiendo que la estrategia para solucionar este asunto es que sean los métodos por el hecho de ser métodos los que sean contenidos en las clases.

Entiendo que no se considera la posibilidad de que haya un método que se redefina en cada instancia... No sé si en ese caso podría solucionarse con un atributo tipo Code.

Lo que no me queda claro es qué hacer con los atributos que no deben copiarse en todas las instancias. El ejemplo más claro son las variables _.autodoc.member.XXX.

¿Existe o existiría la posibilidad de poner "descripción" con el PutDescription a los métodos y demás variables estáticas contenidas en la definición de la clase, o es mejor seguir la estrategia del _.autodoc.member.XXX?

[Víctor de Buen Remiro]

Sí, habrá que inventarse algo para esos campos especiales, vía PutDescription o como sea, para que sea la clase la que gestione esa información, y no las instancias.

[Víctor de Buen Remiro]

(In [1270]) Class instances doesn't store the Class methods that will be stored as just one copy in the Class handler.
Fixed #722