Name of Classes are reserved words

[pgea@…]

Se comenta de paso en el ticket #741, pero creo que merece una atención especial:

¿Se pueden crear clases y otras variables (o funciones) TOL en ámbitos distintos pero con el mismo nombre?

Ahora mismo no se pueden hacer cosas del tipo:

NameBlock Projecto = [[
  Class Concepto {
    Real name;
    Real GetName(Real void) { name }
  }
]];

NameBlock Projecto2 = [[
  Text Concepto = "Nombre"
]];

Si evitar esto es complejo, quizá sería conveniente o recomendable
comenzar todos los nombres de clases con alguna letra o prefijo para prevenir que ocurra.

[pgea@…]

Creo que este asunto es más importante de lo que me parecía en un principio.
Ya que el uso de nombres de clases muy sencillos "bloquea" muchos nombres usados comúnmente.

Por ejemplo ahora (a causa de las definiciones de la StdLib) no podemos hacer una variable o una función (o un método de otra clase) que se llame Probit o Point o Region, ...

[Víctor de Buen Remiro]

El problema es como siempre que el parser necesita que los nombres de tipos sean sintácticamente operadores monarios para que puedan anteceder a una expresión.

Para poder implementar algunas características de la programación orientada al objeto se han ido introduciendo una serie de excepciones para tratar los símbolos monarios de clase como si no lo fueran en determinadas circunstancias resolubles en tiempo de reconocimiento sintáctico.

Sin embargo, la existencia de un símbolo monario es incompatible con que exista otro símbolo con el mismo nombre y al mismo tiempo que sea sintácticamente un argumento, ya que la tabla de símbolos del parser de TOL es única y global, o sea, que no cambia según el ámbito y no puede contener elementos ambiguos sintácticamente.

La única solución viable, para este y otros problemas relacionados con el parser, sería deshacernos por completo del parser actual y crear uno nuevo desde cero, usando alguna herramienta estándar de reconocimiento sintáctico, que creara un árbol sintáctico exactamente igual que el que crea el actual, lo cual sería un trabajo de cirujía a corazón abierto que podría durar varias semanas e incluso meses.

Esto mismo ocurre con los Struct desde siempre en TOL y lo que hizo la gente es llamar a los Struct poniendo prefijos o sufijos del tipo Str o Struct. Lo más sencillo sería hacer lo mismo con las clases y que se usen prefijos o sufijos del tipo Cls o Class.

Se podría recomendar una norma de nomenclatura para Class, o incluso obligar mediante reglas sintácticas a que los nombres de clases comiencen por un caracter especial, ya que apenas existe código que use las clases y sería sencillo cambiarlo, pero realmente sería muy complicado aplicarlo retroactivamente a los Struct, que tendrían el mismo derecho. Aplicar una regla sintáctica de este tipo obligatoria implicaría cambiar el código de todos los proyectos, por lo que sólo veo una salida honrosa que es recomendar en el futuro una norma de nomenclatura común, o al menos análoga, que sirva para clases y estructuras.

[Víctor de Buen Remiro]

La solución adoptada finalmente es la siguiente:

En un futuro no muy lejano se deberá obligar a que todos los tipos definidos por el usuario (Class y Struct) comiencen, ellos y sólo ellos, por el caracter especial @, que no podrá aparecer en medio del identificador.

Sobre las instancias de Class la obligación comenzará desde la siguiente release de la 2.0.1, obligando a cambiar todo el código que lo utilice, que es muy poco por el momento. Como el propio parser dará un error será facil de llevar a cabo.

Para los Struct, como existe demasiado código ya escrito, se plantea una solución intermedia que permitirá durante un plazo, indeterminado todavía, el que existan identificadores que no comiencen por @, pero se recomendará su uso y se permitirá invocar al identificador actual como @<nombre_actual> aunque se llame realmente <nombre_actual>, para ir fomentando su uso. Cuando éste sea mayoritario, y coincidiendo a ser posible con otros cambios drásticos como la reforma de la StdLib, entonces se declarará obsoleta la nomenclatura libre y se obligará a comenzar por @ a los Struct igual que a los Class.

[Víctor de Buen Remiro]

Observaciones:

En la nueva versión todos los Struct vendrán definidos comenzando con @, pero durante la fase de adaptación se permitirá invocarlos sin el @.

Hay que hacer notar que las declaraciones de Struct y las Class no pueden ser ya miembros privados ni de sólo lectura de NameBlock, ya que no pueden empezar por "_", lo cual en principio no parece demasiado grave.

[Víctor de Buen Remiro]

(In [1478]) Fixes #748

[Víctor de Buen Remiro]

(In [1479]) Fixes #748

[Víctor de Buen Remiro]

(In [1480]) Fixes #748
BAnyGrammar find methods also must to search with prefix @

[Víctor de Buen Remiro]

Cuando se cree un Struct sin @ o bien se llame sin @ a un Struct que sí lo tenga entonces TOL no dará error ni warning, pero sí creará una traza en un fichero ubicado en

  TolAppData+"syslog/_non_standard_struct_<TOL session start time>.log"

lo cual podrá ser usado para ir cambiando el código viejo al nuevo estándar.