Le fourre-tout SWT

En plein développement de ma première application SWT, je ne suis pas vraiment dépaysé de Swing, mais après seulement quelques heures, j'ai déjà envie d'étriper celui qui a eu l'idée de mettre toutes les constantes dans une classe unique : org.eclipse.swt.SWT

Je veux bien accepter (difficilement) que des méthodes prennent un simple int pour préciser un type d'objet, mais qu'au moins les types autorisés soient isolés dans une classe correspondante (bon, là c'est pas hyper clair, mais un exemple devrait aider).

Si on considère la méthode notifyListeners, qui prend en argument un type d'évènement (int) et un évenement générique (Event), et bien il faut partir à la pêche dans la classe SWT pour trouver la bonne constante. Bilan : passage obligé par la doc :-(
La 1e fois je me suis égaré en mettant un SWT.SELECTED au lieu de SWT.Selection...

N'aurait pas été plus simple (et propre) d'utiliser une classe interne SWT.Event qui aurait contenu les différents types possibles pour les évènement swing (à défaut de faire mieux) ?

Comments

Popular posts from this blog

3D, multi-core et kernel linux

VoIP, qualité sonore et pipeau marketing...

De l'importance de "final" dans le SWT threading model