Il y a pour moi une grosse différence entre un toolkit et les classes de base d'un langage inclu dans son environnement.
Evidemment que le choix d'un langage et de ce qui va avec créé une dépendance, mais il faut bien coder avec quelque chose, le tookit de base faisant souvent parti du langage et peut donc être considéré comme standard et souvent stable.
Créer une dépendance supplémentaire, vis-à-vis d'un toolkit technique en plus, est par contre plus contestable : on ajoute un risque supplémentaire : il est donc vital de rendre indépendant l'application de ce toolkit en créant les abstractions qui vont bien. Quand il s'agit des threads celà commence à devenir pénible, le toolkit venant s'incruster au plus profond de l'application : on risque d'y perdre en temps et en efficacité si on veut s'en abstraire.
Et le but n'est pas d'etre indépendant à un toolkit, car tu seras toujours dépendant d'un toolkit à partir du moment
C'est comme si je te dis : je suis dépendant de la cigarette, bon allez hop on s'en fou, autant être dépendant aussi à l'alcool ou tout autre forme de drogue.
C'est aussi idiot comme raisonnement : dans notre cas précis on a une dépendance évidente liée au fait qu'il faut implémenter l'appli dans un langage, et lorsque celui-ci propose des services de base il faut les utiliser, notamment la notion de thread. Ce n'est pas une raison pour se rajouter 15000 dépendances inutiles, ou tout du moins ce n'est pas une raison pour ne pas y faire attention et de ne pas ajouter de couche d'abstraction.
Là encore je ne dis pas que wxWidget c'est mal, je veux juste attirer votre attention sur les dangers d'utiliser ce genre de toolkit sans faire un minimum attention à la notion de dépendance.
[^] # Re: tkinter
Posté par TImaniac (site web personnel) . En réponse au journal wxWidgets 2.5.4 disponible sur SF. Évalué à 1.
Evidemment que le choix d'un langage et de ce qui va avec créé une dépendance, mais il faut bien coder avec quelque chose, le tookit de base faisant souvent parti du langage et peut donc être considéré comme standard et souvent stable.
Créer une dépendance supplémentaire, vis-à-vis d'un toolkit technique en plus, est par contre plus contestable : on ajoute un risque supplémentaire : il est donc vital de rendre indépendant l'application de ce toolkit en créant les abstractions qui vont bien. Quand il s'agit des threads celà commence à devenir pénible, le toolkit venant s'incruster au plus profond de l'application : on risque d'y perdre en temps et en efficacité si on veut s'en abstraire.
Et le but n'est pas d'etre indépendant à un toolkit, car tu seras toujours dépendant d'un toolkit à partir du moment
C'est comme si je te dis : je suis dépendant de la cigarette, bon allez hop on s'en fou, autant être dépendant aussi à l'alcool ou tout autre forme de drogue.
C'est aussi idiot comme raisonnement : dans notre cas précis on a une dépendance évidente liée au fait qu'il faut implémenter l'appli dans un langage, et lorsque celui-ci propose des services de base il faut les utiliser, notamment la notion de thread. Ce n'est pas une raison pour se rajouter 15000 dépendances inutiles, ou tout du moins ce n'est pas une raison pour ne pas y faire attention et de ne pas ajouter de couche d'abstraction.
Là encore je ne dis pas que wxWidget c'est mal, je veux juste attirer votre attention sur les dangers d'utiliser ce genre de toolkit sans faire un minimum attention à la notion de dépendance.