Ce que j'ai dit 2 post au dessus:
- je parie: parce que je n'utilise pas régulièrement KDE/QT, je ne peux donc pas savoir.
- la distinction avec les sockets: vu les éléments pertinents que tu a donné dans ton post à ce sujet, je n'ai pas compris ce que disais. Si tu as lu les posts qui le suivent, tu aurais dû t'en apercevoir.
- un préjugé: non, je me sers de composants au boulot sous Delphi et VB (je suis développeur). Les problèmes que je décris sont ceux que je rencontre tous les jours. Alors, je ne connais pas en détail le fonctionnement interne des composants que j'utilise, ce que je sais c'est que je ne peux pas les utiliser pour des problèmes de performance et de stabilité. Avec 64Mo, ce dont je dispose au boulot, il ne faut même pas penser à inclure un composant ActiveX style IE/Word/Excel dans une application et pourtant j'aimerais bien pouvoir le faire.
Ce qui me gène dans l'approche 'composants':
- actuellement, je n'ai vu aucune application raisonablement stable (c-a-d, qui crashe moins d'une fois par jour) utilisant ce genre de systeme alors que j'ai des applis GTK (que j'utilise chez moi, c'est pour ça que j'en parle) ne crashent pas pendant plus d'une semaine et en les utilisant tous les jours.
- les connaissance requises pour manipuler ce genre de concept sont nettement au delà de celles qu'il faut pour faire les même choses sans cette approche (ne serait-ce que parce qu'il faut connaitre des mécanismes de communication, des methodes, etc. en plus de ce qu'il fallait savoir avant). Excuse moi de ne pas être un dieu en prog, même si j'aime bien comprendre un minimum de ce que j'utilise dans mes programmes.
- dans 90% des cas, j'ai (enfin, les gens à mon boulot) un mauvais rapport ressources/fonctionnalités/maintenance/stabilité par rapport à de l'objet classique, et dans les petits projets l'approche objet elle même n'est pas forcément rentable. Et des petits projets, je pense qu'on est nombreux à en faire.
- la réutilisation, c'est bien joli sur papier mais c'est extrèmement difficile en vrai. Une facture chez les assureurs ne ressemble pas structurellement et "comportementalement" à une facture chez un garagiste.
- comme je te l'ai déjà dit ça augmente encore plus le risque de problèmes dûs au code caché (comme pour de l'objet, mais avec en plus des mécanismes de communication opaques)
Ce qui me gène dans vos posts (P. Fremy et toi), c'est que j'ai l'impression que vous présentez l'approche composant/réutilisation un peu comme on a présenté l'objet, les bases de données objet ou le micro noyau: c'est LA manière de faire, LA solution miracle. Je dis juste que je ne le pense pas, que je pense que c'est juste une manière de faire et j'explique pourquoi. Je n'ai rien contre l'objet ou le composant, mais je trouve techniquement idiot de le mettre à toutes les sauces à tout prix.
[^] # Re: Reaction mitigee
Posté par Toufou (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 1.
- je parie: parce que je n'utilise pas régulièrement KDE/QT, je ne peux donc pas savoir.
- la distinction avec les sockets: vu les éléments pertinents que tu a donné dans ton post à ce sujet, je n'ai pas compris ce que disais. Si tu as lu les posts qui le suivent, tu aurais dû t'en apercevoir.
- un préjugé: non, je me sers de composants au boulot sous Delphi et VB (je suis développeur). Les problèmes que je décris sont ceux que je rencontre tous les jours. Alors, je ne connais pas en détail le fonctionnement interne des composants que j'utilise, ce que je sais c'est que je ne peux pas les utiliser pour des problèmes de performance et de stabilité. Avec 64Mo, ce dont je dispose au boulot, il ne faut même pas penser à inclure un composant ActiveX style IE/Word/Excel dans une application et pourtant j'aimerais bien pouvoir le faire.
Ce qui me gène dans l'approche 'composants':
- actuellement, je n'ai vu aucune application raisonablement stable (c-a-d, qui crashe moins d'une fois par jour) utilisant ce genre de systeme alors que j'ai des applis GTK (que j'utilise chez moi, c'est pour ça que j'en parle) ne crashent pas pendant plus d'une semaine et en les utilisant tous les jours.
- les connaissance requises pour manipuler ce genre de concept sont nettement au delà de celles qu'il faut pour faire les même choses sans cette approche (ne serait-ce que parce qu'il faut connaitre des mécanismes de communication, des methodes, etc. en plus de ce qu'il fallait savoir avant). Excuse moi de ne pas être un dieu en prog, même si j'aime bien comprendre un minimum de ce que j'utilise dans mes programmes.
- dans 90% des cas, j'ai (enfin, les gens à mon boulot) un mauvais rapport ressources/fonctionnalités/maintenance/stabilité par rapport à de l'objet classique, et dans les petits projets l'approche objet elle même n'est pas forcément rentable. Et des petits projets, je pense qu'on est nombreux à en faire.
- la réutilisation, c'est bien joli sur papier mais c'est extrèmement difficile en vrai. Une facture chez les assureurs ne ressemble pas structurellement et "comportementalement" à une facture chez un garagiste.
- comme je te l'ai déjà dit ça augmente encore plus le risque de problèmes dûs au code caché (comme pour de l'objet, mais avec en plus des mécanismes de communication opaques)
Ce qui me gène dans vos posts (P. Fremy et toi), c'est que j'ai l'impression que vous présentez l'approche composant/réutilisation un peu comme on a présenté l'objet, les bases de données objet ou le micro noyau: c'est LA manière de faire, LA solution miracle. Je dis juste que je ne le pense pas, que je pense que c'est juste une manière de faire et j'explique pourquoi. Je n'ai rien contre l'objet ou le composant, mais je trouve techniquement idiot de le mettre à toutes les sauces à tout prix.