Ridefinire aree dati

[mtozzi]

I linguaggi gestionali orientati alla gestione complessa dei dati offrono la possibilità di utilizzare un costrutto di redefine. Detto in soldoni si tratta della possibilità di poter trattare un'area di dati (una stringa), che di fatto è un tracciato record contenente diversi campi, in modo omogeneo e quindi poter gestire diversi casi (diversi tracciati record) nel codice semplicemente definendo le strutture dati corrispondenti ed andando a popolare tutti i campi di una struttura in un colpo solo. Questo discorso vale anche per l'elaborazione di file sequenziali (txt con righe a lunghezza fissa) rendendo la gestione degli stessi molto semplice.
Ora come ora in linguaggi simil java e anche in visual code questa gestione diventa molto complicata e di fatto ingestibile vista la complessità dei tracciati record che posso avere anche 20 - 30 - 50 campi. Questi linguaggi non prevedono costrutti ad hoc e gestire la separazione dei campi con dei substring è impensabile.
Vi propongo di implementare in visual code questo costrutto, cioé avere ad esempio la possibilità di definire un imdb con i campi e avere un'istruzione che da una stringa (con campi a lunghezza fissa) sia in grado di popolare i singoli campi estrapolando i singoli valori (e viceversa).

[sfirpo]

Sarebbe comodo poter definire strutture dati gerarchiche cosi come avviene in altri linguaggi gestionali come il COBOL, il Natural o l'Egl.
Nei linguaggi come il Java questo non è possibile, ma la gestione di un'informazione di questo tipo è gestibile solo attraverso l'utilizzo di substring (e quindi è ingestibile, anche perchè, se cambia la lunghezza di uno dei campi, tutto deve essere shiftato).
Ad esempio, in Egl posso definire una struttura dati in questo modo:

Code: Select all

record residenza type BasicRecord
   10 abitazione char(112);
       20 indirizzo char(102);
            30 via char(50);
            30 citta char(50);
            30 provincia char(2);
       20 telefono char(10);
end


Ed accedere ai dati tramite le istruzioni:

Code: Select all

   residenza miaResidenza;
   miaResidenza.abitazione = "abcdefghilmnaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa....GENOVA                  GE010.........";
   miaResidenza.citta = "GENOVA";
   string provincia=miaResidenza.provincia;


Mentre in Java posso solamente scrivere:

Code: Select all

  String miaResidenza = "abcdefghilmnaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa....GENOVA                  GE010........."


e poi provare a gestire il tutto con dei substring.

Questo problema nella nostra realtà è particolarmente sentito perchè spesso le comunicazioni con l'esterno avvengono tramite lo scambio di dati strutturati in questo modo.
La definizione di classi "ad hoc" non è una soluzione perchè, come nell'esempio citato, la profondità della struttura dati può essere maggiore di due.

[g.cassanelli]

E' una richiesta che ho avanzato tante volte, memore della semplicità di spostare centinaia di campi dal record di un file ad un record identico di un altro file con un'unica assegnazione.
Ed anche di estrarre decine di campi da una banale stringa.
Sarebbe veramente utile.
Appoggio in maniera SFEGATATA !!

[a.maioli]

Se qui si parla di parsing di stringhe a lunghezza fissa, è piuttosto facile creare un componente di In.de che lo fa. E' una funzionalità più a livello applicativo che di base, quindi il componente mi sembra la scelta giusta. E qui siamo di nuovo tutti in gioco.

[g.cassanelli]

@a.maioli
Scusa ma non è un parsing di stringhe, è un'altra cosa...

[g.lanzi]

Perché non è parsing di stringhe? Il costrutto in questione, se non ho capito male, a partire dalla sua definizione di campi legge una stringa e la spezzetta in campi.
La cosa che sembra interessante è il fatto che a partire dalla definizione l'operazione sporca viene effettuata dal sistema, che però non può far altro che parsare la stringa.
Come dice Andrea, è possibile creare un componente che renda l'applicazione capace di definire una qualunque gerarchia di schema e di leggere di conseguenza da una stringa. Anche la procedura di ricostruzione della stringa da un record è fattibile, e a questo punto la copia con una sola assegnazione si fa con la chiamata di due procedure.

Possono anche non essere a lunghezza fissa, l'importante è l'algoritmo di lettura a partire da uno schema, ma fatto quello il resto dovrebbe essere in discesa.

[g.cassanelli]

Sì bé in partenza non lo è (un parsing di stringhe).
In Cobol la ridefinizione di un record altro non è che la mappatura di un record (cioè una stringa) in tanti campi, con responsabilità mia di definirli correttamente per tipo e lunghezza.
Quindi assegnando il contenuto di un record ad un altro valorizzo implicitamente i campi del record ricevente con il contenuto del record di partenza. Ed i due records devono essere ridefiniti in modo uguale o comunque compatibile con i dati contenuti nei campi stessi.
Se però si innesta il concetto di lunghezza variabile con identificazione dell'inizio e fine di ogni campo, allora diventa per forza un parsing come lo descrivi tu e sì, come dice Maio è cosa meccanica e non stratosferica.
Diciamo che sia mtozzi che sfirpo sono partiti dal mio stesso punto che già sarebbe un buon passo avanti.
Se poi si aggiungesse la gestione di campi a lunghezza variabile AUTOMATICA (nel senso che non devo fare nulla per gestirla) allora saremmo RICCHI !!!!
Spero di essermi spiegato ;-)
S&B

[g.lanzi]

Il caso fisso non mi sembra molto diverso da quello variabile.
Secondo me con la document orientation, qualche procedura e la reflection, è possibile fare un modo che qualsiasi classe applicativa possa salvarsi e leggersi in una stringa la cui struttura è decisa a run-time, anche multilivello.
Concordo con Andrea, proverei la strada componente.

Se avete voglia di provare, il mio supporto l'avete volentieri.