Le 2013-01-04 15:18, Tony Chemit a écrit :
On Fri, 04 Jan 2013 15:08:27 +0100 Yannick Martel <martel@codelutin.com> wrote:
Salut !
Ca me parait pas une mauvaise idée. Splitter la classe serait une bonne chose (avec ou sans changement de module).
Passer dans un module propre, ça peut être aussi intéressant, mais est-ce vraiment utile ? A part une meilleure visibilité (ce qui n'est pas rien déjà ;), qu'y a-t-il à y gagner ?
Je reste mitigé :\ Il ne faudrait pas non plus ouvrir une brèche vers le "tout-en-minimodule", le simple fait de revoir le packaging suffisant dejà à y voir plus clair, non ?
pour moi non, va voir nuiton-profiling : y'a une classe dedans, donc pour la brèche c'est déjà fait...
Eurk. Mais c'est cependant pas une raison de la renforcer à mon gout ;)
Surtout ce que j'y vois c'est avoir un artifact qui a un but, parce que pour moi ApplicationConfig (nuiton-config) est bien délimité et ne devrait pas être mélangé avec nuiton-utils qui est un foure tout de classes plus au moin pas du tout utiles :(
Là dessus, je te rejoins. Je serais meme partisan de faire un brin de ménage et d'enlever ce qui n'est pas utile, et de tenter de reverser à des librairies (comme commons?) certaines choses (comme StringUtil?). Cela ferait participer aux communautés, et éviterait de réinventer trop souvent la roue et multiplier des dépendances dans les projets :p
ApplicationConfig est bien, je trouve dommage que ça soit au milieu d'un bordel sans nom :( Et c'est plus juste qu'une classe utilitaire vu qu'il a y'a d'autre truc autour.
Avoir son propre module permettrait d'améliorer sa visibilité et pouvoir plus le mettre en valeur, perso je veux utiliser ApplicationConfig mais pas nuiton-utils... et idem je voudrais bien sortir d'autres modules (nuiton-beans, nuiton-converter, ...)
Je suis d'accord, ça me parait même malin :) -- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28