Ok, ho testato per l’intero weekend:
L’intenzione era il refactoring di un architettura esistente, con lo scopo di semplificarla.
Quello che vi riporto e propongo non sono quindi astratte speculazioni, ma veri problemi che si sviluppano nell’utilizzo.
Non ho trovato malfunzionamenti nelle funzioni introdotte, tuttavia sono necessari due aggiustamenti/integrazioni, pena forti handicap nell’utilizzo delle stesse.
-
nella ID Property Definition è necessario (come l’aria che respiriamo!!) inserire la proprietà library !
Oltre al fatto di poter distinguere banalmente un IDdocument da un IDarray etc…, in molti casi è necessario costruire un istanza dell’oggetto: la maggior parte delle volte si tratta di classi applicative. Indipendentemente dal metodo utilizzato per la creazione (tipicamente .getFromDNA(), io mi sono creato una factory più veloce), senza conoscere la library siamo bloccati. Per proseguire il test, ho realizzato un metodo che cerca di indovinare la library dal UIname, funziona nei test ma non è affidabile e non è concettualmente corretto.
-
in caso l’object sia una collection, è importante poter accedere alla proprietà childrenName (in un certo modo analoga alla library di cui sopra), ma sopratutto avere a disposizione il getCollection(index_of_the_property)
Questo punto 2 non è un vezzo: in sua assenza siamo costretti a duplicare tutto il codice di navigazione sulla struttura dati, oltre a duplicare variabili e parametri di funzioni che contengono o si riferiscono agli indici di proprietà. In certi casi è necessario un controllo per capire che proprietà e collection, elaborati in due cicli diversi, non coincidano. In pratica tutto il codice si complica, e non poco.
La possibilità di fare quanto specificato renderebbe tutto più lineare, chiaro, univoco, meno soggetto ad errori, sopratutto in caso di manutenzione o modifica.
note sulla 2:
All’inizio avevo pensato ad una sorta di “cast” della ID Property Definition alla ID Collection Definition, ma in effetti quest’ultima ha molte meno proprietà della prima: l’unica mancanza è proprio childrenName, ma come detto si potrebbe usare library, tutto sommato sono equivalenti (?) Però ci vorrebbe un boolean o metodo .isCollection per la corretta gestione. Tuttavia (esempio in chiave personale), poichè ogni mia collection ha un nome con un pattern preciso, potrei facilmente distinguerla dall’UIname, quindi nel mio caso il booleano sarebbe un optional, ma lo introdurrei comunque per coerenza del sistema.
La getCollection si potrebbe implementare artigianalmente cercando in effetti una collection con lo stesso UIname della proprietà (da quella ricaveremmo anche childrenName), però sarebbe molto più comodo averla nativa: nota inoltre che la proprietà UIname di ID Collection Definition non è mappata nativamente (ma perchè??), ho dovuto farlo io.
I due punti sopra sono fondamentali nella pratica, ne aggiungo un terzo, meno importante ma comunque sensato, vi invito a ragionarci
- fintanto che siamo in questa fase iniziale, ne approfitterei per organizzare diversamente gli attuali metodi
Ovvero, che cosa significa “other_properties”?? beh, io lo so perfettamente, ho aspettato queste funzioni per anni, ma mettevi nei panni di un nuovo utente, o di un primo approccio alla reflection: le funzioni normali operano sulle proprietà scalari pubbliche, quelle “other” sulle scalari private e sulle object. Per distinguere le private dalle objec ho a disposizione la proprietà private… ma cosa succede se ho una proprietà sia object che private? ok, si trova la soluzione, si usa data type, ma capite che la cosa è male organizzata?
Do per scontato sia necessaria la retro-compatibilità, ma ragionate un secondo:
Se la retro-compatibilità non fosse necessaria avremmo due soluzioni naturali e logiche:
A- un’unica serie di metodi, per enumerare e gestire tutte le proprietà, con due booleani (nel property definition) che indicano se private e/o se object
B- due serie di metodi, come sopra, una dedicata alle proprietà scalari ed una alle object, con la sola proprietà booleana private
Se vogliamo mantenere la retrocompatibilità:
A- un’unica serie di metodi (quella attuale), con due flag opzionali per includere gli object e/o le private, e due relativi booleani nel property definition
B- due serie di metodi, una per le scalari (quella attuale), e una per le object (nuova), entrambe con il solo flag private
Quindi, non si tratta di non riuscire a lavorare (come il punto 1 e 2) , ma di rendere il sistema più razionale per chiunque dovrà utilizzarlo. Considerando il valore che rappresenta la reflection dentro ad inde, io ci investirei un attimo di tempo e farei le correzioni proposte.
Immagino di essere l’unico che ha provato a lavorare con queste nuove funzioni, siete ancora nella fase calda della implementazione, impatto ed effort saranno minimi.
