About Proposed-Changes

[cano-hernan]

Proposed-Changes.txt

• Se debe revisar si el JsonFox.prg final debe ser UTF8 o si debe ser ANSI, ya que los caracteres gráficos se ven mal.
  Si bien en cuanto a comentarios no importa, he notado que hay algunos caracteres como por ejm
  en las funciones
  hidden function peek
  hidden function peekNext

hay un caracter gráfico en el RETURN de cada una.

• Hay muchas estructuras WITH/ENDWITH con la deficiencia de tener un RETURN dentro de ella.
  Por ejm:
  hidden function advance
  with this
  .current = .current + 1
  return substr(.source, .current-1, 1)
  endwith
  endfunc

y lo mismo con
hidden function peek
hidden function peekNext
hidden function identifier
hidden function number(tChar as Character)
hidden function string
function isAtEnd
... y muchas más.

• Considero que la vble privada JSONUtils ya no es necesaria.
  private JSONUtils

Si alguien me indica que no debe suprimirse, me aclara.
Creo q puede suprimirse y dejar que cada clase/objeto use su propia
this.oUtils

• Tanto en la anterior
  define class JSONClass as session
  que está en src\jsonclass.prg

como en la nueva
define class JSONFox as session
que está en src\jsonfox_class.prg

hay un bug de programación.

En el Init de la nueva class JSONFox está (q luce bien):
function init
this.aCustomArray[1] = .null.
this.oUtils = createobject("JSONUtils")
this.lTablePrompt = set("TablePrompt") == "ON"
set tableprompt off
endfunc

y el Destroy de ambas está:
function destroy
try
if this.lTablePrompt
lcTablePrompt = this.lTablePrompt
set tableprompt &lcTablePrompt
endif
catch
endtry
endfunc

Si .lTablePrompt es lógica/booleana, entonces el SET TABLEPROMPT en el Destroy es incorrecto.

Quizá no se ha detectado el problema, por que está dentro de un TRY/CATCH mudo.

• Quisiera saber si en
  function getValue as string
  está faltando o no

B = Double

en el comando
case tctype $ "YFIN"

¿O será que es correcto que esté en
case tctype $ "CDTBGMQVWX" ?

Resp HCano: lo lamento: pienso q no.

• Me parece que los tipos Fecha y FechaHora en
  case tctype $ "CDTBGMQVWX"

        case tctype == 'D'
            tcvalue = '"' + strtran(dtoc(tcvalue), '.', '-') + '"'
        case tctype == 'T'
            tcvalue = '"' + strtran(ttoc(tcvalue), '.', '-') + '"'
  

deben cambiar a

        case tctype == 'D'
            tcvalue = '"' + left(ttoc(tcvalue,3),10) + '"'
        case tctype == 'T'
            tcvalue = '"' +      ttoc(tcvalue,3)     + '"'

pues tanto DTOC como TTOC --en la forma en que están escritos ahí, originalmente-- dependen de SET DATE, SET CENTURY, SET ROLLOVER, SET MARK, SET POINT, etc.

• En la función
  function AnyToJson as memo

la vble llIsCollection necesita ser definida como LOCAL.

[cano-hernan]

• La propiedad LastErrorText fue descontinuada. Ahora es cLastError, pero en combinación con lError.
• Quizá sea conveniente hacer el sgte ajuste en SetError():

        this.lError    = .t.
        if !empty(this.cLastError)
        this.cLastError = alltrim(this.cLastError) +CRLF
        endif
        this.cLastError = alltrim(this.cLastError) + tcMsg
    endfunc

[Irwin1985]

Gracias @cano-hernan por el análisis detallado. He subido la versión 1.1.0 que lleva los siguientes cambios:

1. Bug en Destroy con lTablePrompt: Tenías razón. La variable lógica .T./.F. se expandía con macro &lcTablePrompt produciendo SET TABLEPROMPT .T. que es inválido (espera ON/OFF).

2. DTOC/TTOC dependientes de SET DATE: Correcto. DTOC() y TTOC() dependen de SET DATE, SET CENTURY, SET MARK, etc. Se reemplazó por TTOC(val, 3) que produce formato ISO 8601 independiente de la configuración regional: "yyyy-mm-dd" para fechas y "yyyy-mm-ddThh:mm:ss" para datetime.

3. llIsCollection sin LOCAL en AnyToJson: Bug real. Como AnyToJson es recursiva, la variable implícita se compartía entre llamadas. Se agregó LOCAL llIsCollection.

Puntos que no se aplicaron:

• Caracteres gráficos en peek/peekNext: Los había arreglado antes pero no había hecho el upstream.

• RETURN dentro de WITH/ENDWITH: Este es un anti-patrón conocido pero funcional en VFP. Lo dejo por ahora como refactor de menor prioridad.

• private JSONUtils: Es un patrón intencional para compartir la referencia en el call stack sin pasarla como parámetro a cada función hija. No es un bug.

Prueba y me avisas si todo va bien para cerrar el issue.

Un saludo.

[cano-hernan]

Procedo a revisar......
Además.....

Primero:
Me gusta el manejo q la nueva define class JSONFox as session

hace con los errores en la hidden function SetError(tcMsg)

Veo que está en las sgtes funciones de la misma clase:
CursorToJSON
JSONToCursor
CursorToJSONObject
CursorStructure
MasterDetailToJSON
ArrayToXML
XMLToJson

Quiero q en la misma clase, las sgtes funciones --q son públicas--
Parse
Stringify

también hagan el mismo trabajo con los errores.
Estoy editando el JsonFox.prg para lograrlo.

Segundo:
En la procedure
hidden function saveEnvironment

¿sólo
set("POINT"), y
set("SEPARATOR")
hacen parte del Environment?

¿Qué hay de...? set datasession set tableprompt set("Century") set("Date")

Tal vez edite el JsonFox.prg para lograrlo.

Tercero:
En la clase Tokenizer define class Tokenizer as session

Veo que la propiedad .sourceLen recibe la longitud/tamaño/(cant caracteres) de len(tcSource):
.sourceLen = len(tcSource)

donde tcSource es el contenido/string del archivo que se va a revisar.

Pero entonces veo en .isAtEnd y en .peekNext
function isAtEnd
return this.current > this.sourceLen
endfunc

hidden function peekNext
if (this.current + 1) > this.sourceLen
return '�'
endif
return substr(this.source, this.current+1, 1)
endfunc

que se compara con .Current, que --por lo q he visto-- es el contador actual de Tokens que se están revisando.

Por cierto: estos son los car gráficos que digo que son eventualmente problemáticos: en Peek, y en PeekNext.

[cano-hernan]

En la clase define class JSONFox as session

en la función function getString as string

veo raro el ajuste que te muestro en la imagen
((en cuanto a escapar algunos caracteres especiales))

		** OPTIONAL ESCAPES
		if tlParseUTF8
			** Special characters
			tcString = strtran(tcString,"&","&")
			tcString = strtran(tcString,"+","+")
			tcString = strtran(tcString,"-","-")
			tcString = strtran(tcString,"#","#")
			tcString = strtran(tcString,"%","%")
		endif

[cano-hernan]

¿Será que B está bien ubicado con esos otros tipos?

[cano-hernan]

### Acerca de Date/DateTime:

He estado analizando la forma en que JsonFox detecta los campos Date y DateTime.

Me complace que tenga manejo para cuando se recibe una fecha (o sea que así está en el JSON) en formato que yo llamo internacional:
YYYY-MM-DD
con separador guión, o slash (me parece q falta punto, pero no es restrictivo).
En el ámbito de la Informática al formato que inicia con año a cuatro dígitos se le llama ISO-8601.

Y --en general-- es fácilmente sistematizable.

De la misma forma veo que JsonFox también tiene manejo para el formato
DD-MM-YYYY

Sin embargo no me es muy grato, porque pienso que no es muy acertado, ya que puede ser confuso cuando el formato que se use sea
MM-DD-YYYY

Considero que es tal vez por q lo usas tú mismo personalmente (el formato DD-MM-YYYY).

Pero me parece que no es correcto que una utilidad/utilería/librería tenga para un formato sí y para el otro no, porque precisamente porque
01/05/2026
puede dar correcto tanto para DD-MM-YYYY como para MM-DD-YYYY

.......... a menos --claro-- que la librería sólo le dé soporte a DD-MM-YYYY !!!!!..........

Hice una consulta a Google
How to check if a string is date in Chilkat?

Y me respondió como ves en el .PDF .

La conclusión (como yo lo veo es):

1. El formato YYYY-MM-DD es genérico y es viable sistematizar.
2. Los formatos DD-MM-YYYY y MM-DD-YYYY no son genéricos y no se recomienda sistematizarlos... a menos que se usen librerías específicas (para los que quieren pegarse a las dificultades).
3. Otro formato que también es genérico y es viable de sistematizar es
   Wed, 17 Jun 2026 16:33:00 GMT
   ((porq el mes está en letras, en un formato incuestionable/inconfundible))

y precisamente iba a sistematizarlo (editar JsonFox.prg para permitirlo), pero mi gran conclusión es:

"""Los formatos DD-MM-YYYY y MM-DD-YYYY no son genéricos y no se recomienda sistematizarlos"""
((en el entendido de que hablamos de que así vengan en el .JSON/.XML))

CONCLUSION con respecto a JsonFox:
En mi estilo de programación, prefiero sólo convertir (adecuadamente) si la fecha en el JSON (o en el XML) está en el formato internacional/ISO8601/RFC3339.
Y si el tiempo y recursos me dan, también el formato RFC822.

Si la fecha está en un formato que empiece por DD o por MM, prefiero dejarla en Character, y posteriormente (en un script en .PRG posterior a la serialización JSON) hacer la conversión que sea posible/adecuada/necesaria/acorde/disponible.

En JSonFox: ¿existe forma de impedir que JsonFox serialice Dates y DateTimes, o que sólo serialice si la fecha es ISO8601?

How to check if a string is date in Chilkat - Google-IA.pdf

[cano-hernan]

La correción correcta es
set tableprompt &iif(this.lTablePrompt, 'ON', 'OFF')