[Dcmlib] Chasse aux methodes qui devraient etre 'cachées'

[Jean-Pierre ROUX]

Bonjour.

L'histoire de (uint16_t group, uint16_t elem) vs TagKeg key, soulevée 
par Mathieu me fait penser (de nouveau) aux soucis de l'utilisateur 
qui voulait utiliser des methodes (publiques) de 
gdcm::PixelReadConvert.

Il est clair qu'il faut se donner les moyens de 'cacher' de telles 
methodes, pour eviter toute confusion.
En l'absence d'<<embedded classes>> ou d'<<embedded methods>> en C++, 
la seule solution, c'est 'friend'.
Benoit avait fait un grand mémage pour virer les declarations 
'friend' qui avaient été mises de maniere abusives, et il a bien eu 
raison.

Le pb, c'est qu'il a viré *egalement* celles dont la présence était 
parfaitement justifiée.
On se retrouve donc avec des méthodes 'publiques' dont aucun 
utilisateur ne peut se servir sans tout péter (j'avais identifié dans 
mon code un certain nombre de fonctions comme 'not end user 
intended', mais ca serait encore mieux si l'end user ne les voyait 
pas ...)

Il faudrait, à mon avis, qu'on se mette d'accord (Mathieu+Benoit+moi) 
sur la manière précise dont on s'y prend pour résoudre ce pb (qui 
allègera du coup l'avalanche de méthodes qui assaillent 
l'utilisateur), faire un sequencing de l'ensemble du 
bazar(Benoit+moi), et mettre bon ordre a tout ça (moi).

JP
  Jean-Pierre ROUX
  CREATIS - CNRS UMR 5515, INSERM U 630
  Laboratoire de Radiologie Experimentale
  Hopital Cardiologique
  28 Avenue du Doyen LEPINE
  B.P. Lyon-Montchat
  69394 Lyon Cedex 03

  Tel      : (+33) 04 72 35 74 12
  Fax      : (+33) 04 72 68 49 16
  URL      : http://www.creatis.univ-lyon1.fr
  e-mail   : jpr at creatis.univ-lyon1.fr