TODO

Logger:
    - mettere i log a tappeto in tutte le classi con il livello adeguato (error, warn, info, debug o trace)
        - throw Exception() -> error
        - System.err -> error
        - System.out + "Warning" -> warn
        - System.out -> info
        - metodi di operazioni (non quelli che delegano) -> debug
        - metodi che delegano -> trace


Trovare un modo per poter condividere Configuration (variabile di Mapper) con tutte le altre classi
senza dover passare "mapper" ovunque (e quindi magari anche recuperare il mapper senza doverlo ogni volta passare!):
    • ThreadLocal?
    • Map<id,Config> statico?
    • Mapper.Manager con Map<id,Config> statico e ci si accede tramite metodo Mapper.Manager.config(idMapper)
        con questa soluzione non si passa Mapper a ogni classe che lo usa, ma si passa idMapper unico per ogni istanza di Mapper
        idMapper: da creare e alla creazione di un Mapper, viene inserita nel Manager la coppia {idMapper,mapper}
        metodi nel Manager:
            - addMapper(Mapper mapper) { MANAGER.put(mapper.getId(),mapper); }
            - getMapper(int idMapper) { return MANAGER.get(idMapper); }
            - getConfig(int idMapper) { return getMapper(idMapper).config(); }


DeepCopy:
    - aggiungere la possibilità di specificare di fare un "deepClone" di un singolo field oppure di escluderne alcuni:
        @DeepCopy { // senza niente implica che va applicato a tutti i field se messo a una classe, oppure il field se messo a un campo
            booolean ignore() default false;
            String[] ignoreFields() default {};
            String[] ignoreAllExceptFields() default {};
        }
        aggiungere di conseguenza un "deepCopyEnabled" dentro il FieldHolder da leggere poi in fase di mapping
    + attualmente viene fatto sempre o mai, è specificato dentro Configuration.java


AliasName:
    negli alias dell'annotazione, mettere la possibilità di specificare un campo annidato, come ci si accederebbe in js
        - contro: se è presente un array, la logica diventa incasinatissima, limitare solamente agli oggetti "singoli"?


per il campo "Class<? extends DefaultValueFactory> factory()" dell'annotazione @Default:
    creare un DateFactory già incluso dentro la libreria in quanto potrebbe essere frequentemente usato

    ne deriva che si potrebbe creare un package (mapper.implementations? es.utils.implementations?) dedicato alle
    implementazioni "utili" che non riguardano il mapping ma solamente la personalizzazione da parte dell'utilizatore


Rimuovere gli step opzionali DefaultInput e DefaultOutput che diventano ripetitivi rispetto a defaultValue() presente
in Transformer?
    pro: Riduce notevolmente il numero di combinazioni possibili per il Builder (da 20.162 a 1.586), ma aggiunge flessibilità di utilizzo
    contro: sembra che in tal caso vada rivista anche la logica dentro ElementMapper.defaultValueGetter() e ElementMapper.defaultValueSetter
            perché il test case DefaultValueTest.shouldCreateEmptyObjectWithDefaultValuesCustom() non viene superato (unico test che non viene superato)


Rivedere DefaultValueStrategy: attualemente ci sono 5 valori presenti nel enum (NEVER, DEFAULT, ALWAYS, CUSTOM, INPUT e OUTPUT):
    La logica viene influenzata solamente da INPUT e OUTPUT, perché tenersi tutti gli altri?