Discussion :

[chaplin]

Bonjour,

Il est difficile de juger un produit dans un délai aussi court de 14 jours.
J'étais attiré par Datasnap, la démonstration des possibilités d'unicode
à la conférence de Paris était étonnante quant à sa mise en oeuvre

J'imagine que pour ceux qui sont amenés à faire une mise à jour dans
cette version, c'est une mission insurmontable. Je me souviens
d'un temps ou on m'avait insité à aller vers un autre outil de développement.
Dans ces cas il faut tout remetre en cause, peser les pours et les contres.
J'avais fais le paris de passer à la nouvelle version de Delphi, plusieurs
années après les programmes tournent toujours malgré tous les virages
technologiques de Microsoft. Bien entendu, il fallait remettre tout le code
à plat, mais ce qui importe le plus ce sont des bonnes méthodes plus que
le code. A l'époque, les technologies étaient émergentes, 4GL et L3G.
Je devais auditer le code moi-même, aujourdh'ui je fairais
appel à un expert du développement Delphi. Changer de langage peut aussi
signifier changer de développeur(s), attention !!

[Franck SORIANO]

Les génériques...sont ...hummm dit avec gentillesse très simplets.
essayez de faire une procédure générique en dehors d'une classe...bein oui on peut pas, il n'y a pas moyen de déclarer un type générique en dehors d'une structure (interface, classe et record). Vous êtes obligé de créer une classe avec la procédure en t'en que "class procedure" pour feinter.

C'est tout ce que tu reproches aux générics ? Ne pas pouvoir faire de générique sur procédure toute simple ?
Je trouve que c'est un peu léger pour dire que c'est très simplet.

Le grand intérêt des génériques, c'est qu'en même de pouvoir ensuite définir des structures de données génériques (les collections en particulier), tout en conservant un typage fort. Aujourd'hui, si tu veux faire une liste, soit tu utilises un TList directement et tu ne peux pas typer les données. Soit tu dérives un TCollection et TCollectionItem ce qui t'oblige à créer une nouvelle classe.
J'espère qu'en gérant les générics, CodeGear en a profité pour implémenter toutes les collections génériques dont on dispose en .Net : IList<T>, IDictionnary<K, V>...

Les méthodes anonymes avec générique ça fonctionne , enfin faut faire gaffe avec les overload, je me suis retrouver avec une erreur interne,...

L'IDE reste fidèle à elle même...

[Andnotor]

si un outil résolvait tout : que ferions nous !

On se concentrerait sur de nouveaux développements

Mise à part, je trouve toutes les remarques dans ce forum plutôt négatives.
Autant je comprends que lorsqu’on utilise D2007, les rares nouvelles fonctionnalités de l’EDI paraissent dérisoires, j’ai beaucoup plus de peine à comprendre les personnes qui utilisent D6 ou D7.

Code completion, refactoring, simplifier la visualisation du code par des $REGION, etc. rendent quant même la vie plus facile…

Je n’aime pas beaucoup la lourdeur de l’EDI (Héritage lui aussi de Delphi .NET ou D8). Certaines fonctionnalités sont pourtant très attractives.

Après unicode et png, mon souhait pour le futur est enfin le support des appareils mobiles puisque Windows Mobile accepte Win32 depuis la version 6.

[Suryavarman]

C'est tout ce que tu reproches aux générics ? Ne pas pouvoir faire de générique sur procédure toute simple ?
Je trouve que c'est un peu léger pour dire que c'est très simplet.

Le grand intérêt des génériques, c'est qu'en même de pouvoir ensuite définir des structures de données génériques (les collections en particulier), tout en conservant un typage fort. Aujourd'hui, si tu veux faire une liste, soit tu utilises un TList directement et tu ne peux pas typer les données. Soit tu dérives un TCollection et TCollectionItem ce qui t'oblige à créer une nouvelle classe.
J'espère qu'en gérant les générics, CodeGear en a profité pour implémenter toutes les collections génériques dont on dispose en .Net : IList<T>, IDictionnary<K, V>...


L'IDE reste fidèle à elle même...

Bein c'est déjà asse gros comme soucis, suffit de regardé mon exemple. Je vais pas créer une classe pour chacune de mes procédure, et si je les met toute dans une classe, j'ai pas envie de définir tout un bloc de procédures pour un type alors que j'aurais besoin que d'une procédure. Sinon c'est un bon début mais j'espère que leur syntaxe va évoluer, car elle part déjà mal. Si il la change faudra encore revoir nos centaines de milliers de code. Car là c'est plutôt des tiny générique. Enfin bon ça n'empêche en rien de faire des trucs bien pratique .

Pour les structure de données faut pas rêver, CodeGear va juste attendre qu'un rigolo les faces et lui rachèterons.

[Franck SORIANO]

Bein c'est déjà asse gros comme soucis, suffit de regardé mon exemple.
...
Pour les structure de données faut pas rêver, CodeGear va juste attendre qu'un rigolo les faces et lui rachèterons.

Je crois que tu as essayé de transposer la STL du C++ sur les générics de Delphi. Mais justement, les générics ne sont pas des template. C'est certainement pour ça d'ailleurs qu'ils ont rencontré davantage de succès dans dotNET que ce que les templates ont eu en C++.
Les générics de dotNET ne permettent pas non plus de travailler sur des procédures externes à une classe (forcément, en dotNET tout fait forcément parti d'une classe).

Pour ce qui est des structures de données, si on regarde le tuto de nono40 publié ce matin, CodeGear a au moins définit la classe TList generic (qui dérive de TEnumerable d'ailleurs ce qui veut dire qu'elle doit supporter le foreach nativement ).
De plus, s'ils ont également ajouté le Equals et GetHashCode, c'est sûrement qu'ils ont aussi fait le dictionnaire...

[Suryavarman]

Pourquoi continuent ils de se rapprocher de .Net ?
En delphi tout ne fait pas parti d'un classe.

d'ailleurs qu'ils ont rencontré davantage de succès dans dotNET que ce que les templates ont eu en C++

... heu sur quoi tu te base.

Pour ce qui est des structures de données, CodeGear a au moins définit la classe TList generic (qui dérive de TEnumerable d'ailleurs ce qui veut dire qu'elle doit supporter le foreach nativement ).
De plus, s'ils ont également ajouté le Equals et GetHashCode, c'est surement qu'ils ont aussi fait le dictionnaire...

Voui ...ça vole pas haut, la jcl elle fait des structures de données dignes de ce nom.

Je crois que tu as essayé de transposer la STL du C++ sur les génériques de Delphi

C'est qu'un truc tout bête que j'ai fait, les noms oui s'inspirent de la stl. Mais c'est bien dans cet esprit que je comptait utiliser les génériques.

[ShaiLeTroll]

Aujourd'hui, si tu veux faire une liste, soit tu utilises un TList directement et tu ne peux pas typer les données. Soit tu dérives un TCollection et TCollectionItem ce qui t'oblige à créer une nouvelle classe.

Perso, j'ai un template de TList hérité fortement typée, un peu dans l'esprit du ListCreator que l'on trouvait sur Developpez.com ... j'ai toujours aimé codé mes listes typés avec des pointeurs de record, en gérant la libération par la liste le plus que possible, faire mes propres hiérarchie arborescente ... et cela en Delphi 3 ! hi hi ! Ah la bonne époque où pour faire un tableau dynamique il fallait utiliser un pointer sur array et faire un GetMem ... aaahh ... ça c'était formateur, ... le SetLength, quel grande avancée utile en D4 !

Après les histoires de génériques, j'avoue je n'ai pas pigé toute l'utilité, ... ah et cela ne fonctionne qu'en objet, euh Delphi c'est pas censé être un langage objet ? c'est vrai qu'il reste très procédural (jusqu'à D7 après je ne sais pas ...), moi la seule chose qui m'a manqué c'est les propriétés de classe, à part tout ça, combien utilise tous ces concepts "new age" de la POO dans leur application au quotidien (tout en respectant délai et coût fixé par son Responsable Projet)

colfire_dev, tu trouve que Delphi était en retard par rapport à VS, ouch, l'IDE était le meilleur de tous, Créer des fenêtres en VSC++ c'était la misère (Anchors, Align, ... c'est du code Delphi, c'est pas Window qui le gère) ! avec le .NET (WinForm ???), cela doit être mieux ... le gros problème en Delphi, c'était de trouver des Headers des API Windows à jour (heureusement, il y a Jedi) maintenant, j'ai l'impression que Delphi est à la traine, mais je me sens à peine concerné, j'ai pas dépassé D7 (bien que cela en déplaise à Andnotor) ... pour moi D2009 est une curiosité, rien de plus, aucun intérêt, aucun enjeu dans ma boite, c'est juste professionnellement parlant, une évolution à ne pas louper (D7 à D2009, ça fait un sacré bond)

j’ai beaucoup plus de peine à comprendre les personnes qui utilisent D6 ou D7.

lol, tu oublie D5 !!! Ce genre de remarque, ça me fait marré, il y a encore 2 ans, j'étais en Delphi 3, le plus drôle, c'est que je développais tout en Delphi 7, et comme le framework de la société gérant les clients en D7 (lib interne V6) n'était installé qu'à 10%, eh bien, je recodais tant bien que mal, tous mes programmes en D3 (lib interne V4) cela avec des directives de compilation dans le code pour gérer des DFM séparées mais un code commun, la rigolade quoi ... le plus drôle étant la différence de comportement des variants et du TClientDataSet (lui aussi une version bidouillé de Delphi 5 intégré en Delphi 3, et rebidouillé pour Delphi 7 ...)
Imagine donc une société avec 10 000 clients, près de 7 000 servers applicatifs, 100 000 postes utilisateurs, tu fais comment pour migrer tout ça dès que tu change de version de langage quand tu vends des logiciels de Compta, RH, Paye, Santé Publique, Informatique Hospitalière, maintenus par une cinquantaine de developpeurs, ... ça c'est la réalité, c'est l'ARGENT, tu n'as pas de budget, et bien tu bouges pas, ... tu as attends, tu recules, pour mieux sauter (et parfois tomber) ... et puis les clients n'ont pas que ça à faire d'acheter version sur version ...

Je ne suis plus dans cette société, mais finalement, ma situation n'a pas changé, je m'occupe toujours d'une application qui a un historique très lourd, une structure de base de données conçus en Clipper (il y a plus de 10 ans) reprise en Delphi 5 et 6 en DBase via Appolo en 2002, puis traduite à la sauvage en Delphi 7 MySQL via MyDac-CoreLab en 2005 (ouais ils étaient déjà à la bourre), et ça ce n'est qu'une application, avec 60 servers, 500 postes utilisateurs, tu as comme ça une bonne dizaines d'applications (certaines déployés à encore plus grand echelle et encore en DBase) et l'on est 2 (et demi) developpeurs à maintenir tout ça ! Ah est-ce que tu comprends mieux

[Andnotor]

Joli jonglage
Et pourquoi pas D2009 en D3

[ShaiLeTroll]

Je pense qu'il y a des limites à la connerie, maintenir des applications en D3 et D2009 en simultané ne doit pas exister (j'espère, ça me ferait bien marrer de voir ça), je pense qu'en même que ceux qui ont fait le pas de passer en D200x on du abandonner les Delphi plus anciens (sauf le 7 à la limite) ... ou en tout cas, il n'y a pas d'interaction directe entre ces programmes (sources communes par exemple)

[Franck SORIANO]

Pourquoi continuent ils de se rapprocher de .Net ?
En delphi tout ne fait pas parti d'un classe.

C'est vrai. Mais aujourd'hui, la mode est plutôt au tout objet. Et Delphi est avant tout un produit commercial. J'imagine que CodeGear n'a pas dû ressentir le besoin d'en faire plus que .NET (ou ils n'ont p-e même pas pensé que ça intéresserait quelqu'un).

... heu sur quoi tu te base.

C'est mon sentiment personnel. Je connais beaucoup de dev C++ qui voient les templates comme une curiosité plus que comme quelque chose d'incontournable.
En revanche, en C# tout le monde s'est mis aux génériques (ne serait-ce que pour utiliser les structures de données et les événements).

De plus pour ainsi dire aucun language majeur n'a voulu reprendre le concept des templates (tout comme l'héritage multiple). Sun n'en a pas voulu dans Java. Microsoft n'en a pas voulu non plus dans .NET, par contre ils ont améliorer le concept en faisant les générics.
Et les générics par contre ont eu un succès suffisant pour forcer Sun à les reprendre dans Java.
Même CodeGear a finalement dû implémenter les generics dans Delphi alors qu'au départ, ils ne voulaient pas ajouter les types paramétrés au langage...

[Andnotor]

Cette conversation tourne de toute façon en rond...

Si à peine tu recompile une application cliente, il faut changer toutes les applications serveurs, c'est que dés le départ tes prédécesseurs ont mal pensé leurs développements (et dans ce cas, je te plains). C'est pas parce qu'on est passé de Indy 9 à Indy 10 qu'on a changé tous les serveurs HTTP, FTP, etc. de la planète.

Libre à tes clients de savoir s'il veulent acheter un upgrade ou pas. Doit-on pour cela limiter l'évolution histoire de ne pas les froisser?

Je pense qu'il y a des limites à la connerie...

Dois-je me sentir visé ?

En parlent de downgrade. Est-ce que quelqu'un à remarqué le retour des composants TTcpClient et TTcpServer dans la palette des composants

[Suryavarman]

C'est mon sentiment personnel. Je connais beaucoup de dev C++ qui voient les templates comme une curiosité plus que comme quelque chose d'incontournable.

pour ma pare c'est l'inverse. Mais c'est peut être parce que je bosse dans le monde de la 3D, besoin de performances, donc d'avoir un max de truc déterminés lors de la compilation.

Je diminue ma critique dans ce cas, leur génériques sont biens, mais pas exceptionnels . J'arriverais bien à m'accommoder de pas pouvoir déclarer de procédure/fonction générique hors structure.

[ShaiLeTroll]

Dois-je me sentir visé ?

Cela ne t'était pas adressé, mais envoyé au large pour ceux qui aurait l'idée saugrenue de maintenir des applications avec du code commun entre D3 et D2009, qui doivent être totalement incompatile, je pense par exemple à des composants externes, TMS ayant parfois eu le courage de maintenir de D5 à D2006 ! C'est la limite du raisonnable ...

Maintenant, est-ce que tu as toujours de la peine à comprendre les personnes qui utilisent D6 ou D7 ?

Pour les applications Servers et Clients que j'avais à cette époque, c'est la gestion des Threads des Objets Automations qui avait changé entre D3 et D7, et lorsque tu as tout une architecture COM\DCOM interfaçant une application cliente se basant sur un échange de binaire pour le contenu des Tables (Oracle ou SQL Server) via la propriété Data Variant d'un TClientDataSet bidouillé et que la gestion des variants à aussi changé ... eh bien, tant que le Serveur n'a pas été mis à jour, eh bien tu ne peux pas déployer le client car ils ne sont plus en phase,

Evidemment tu cite HTTP et FTP, deux protocoles strictement définie, et Indy respect les spécifications de ces protocoles. Je n'ai jamais dit que la communication entre Servers et Clients étaient strictement définie dans mon cas, j'ai bien dit que c'était une grosse bidouille ...

c'est que dés le départ tes prédécesseurs ont mal pensé leurs développements (et dans ce cas, je te plains).

Jusqu'à présent, j'ai toujours trouvé quelque chose à critiquer, peut-être parce que j'adore ça, je me dois de conserver mon titre de Troll !

Tu travailles dans quoi ? Tout est parfait dans ce que tu fais ou ce que tu dois maintenir ? Tu dois t'ennuyer non ?

Pour TTcpClient et TTcpServer, je ne savais même pas qu'ils avaient disparu, lol, j'ai encore des TClientSocket et TServerSocket, lol, je dois avoir un programme qui tourne 24/24 depuis 2003 avec ces composants Je n'ai jamais compris pourquoi ils avaient été retiré ..

[helmis]

en Delphi 2009 on est toujours limité au Int64(64*bits signé) ??

[Reisubar]

Limité ? Le type Int64 est un type qui restera à jamais un entier signé de 64 bit, quelque soit la version de Delphi...

[madfu]

J'ai l'impression qu'il n'y a toujours pas de driver dbexpress pour postgresql dans cette version vous confirmez ?

[helmis]

Limité ? Le type Int64 est un type qui restera à jamais un entier signé de 64 bit, quelque soit la version de Delphi...

J'ai souvent eu des Problèmes avec Delphi en voulant vérifier des codes Bancaires et autres codés sur 128bits & 256bits et plus , il y'a des libs open source pour ça mais elle ne sont pas validé, d'ou j'ai du coder ces dernière (Procedure & Fonction) sous Oracle PLsql et récupérer le résultat sous forme de String.

[ShaiLeTroll]

J'ai l'impression qu'il n'y a toujours pas de driver dbexpress pour postgresql dans cette version vous confirmez ?

Ils en ont parlé durant la présentation, je ne me rappelle plus exactement de ce qui a été dit, mais il semblerait que cela soit en projet ...

Sinon Helmis, le registre maximal est de 64bits, ils ont fait le Int64 pour compenser les limitations des processeur 32bit, maintenant le Int64 doit être implementé différent selon si l'on compile pour 32 ou 64 bits ... enfin pour ton problème de code sur 128 ou 256, cela m'étonne que tu les gère sur via des nombres ... des calculs comme le CRC32 ou SHA, ce font sur des binaires sans éprouver le besoin de passer par un nombre ou par des strings, je vois par exemple les codes-barres 3D, c'est un binaire, pas un nombre, donc c'est stocké en BLOB pas en chaine ... rien pour que les problèmatiques de CharSet, le stockage en chaine est périlleux

[chaplin]

Citation:

Envoyé par ShaiLeTroll

Imagine donc une société avec 10 000 clients, près de 7 000 servers applicatifs, 100 000 postes utilisateurs, tu fais comment pour migrer tout ça dès que tu change de version de langage quand tu vends des logiciels de Compta, RH, Paye, Santé Publique, Informatique Hospitalière, maintenus par une cinquantaine de developpeurs, ... ça c'est la réalité, c'est l'ARGENT, tu n'as pas de budget, et bien tu bouges pas, ... tu as attends, tu recules, pour mieux sauter (et parfois tomber) ... et puis les clients n'ont pas que ça à faire d'acheter version sur version ...

Je pense que le problème ne conçerne pas seulement Delphi. D'autres projets avec d'autres languages
sont dans le même cas de figure. C'est une erreur de la part des dirigeants d'une entreprise
de sous estimer l'investissement dans leurs programmes, car ils oublient que c'est leur fond de commerce.

Les mise à jours, si elles s'avèrent contraignantes parce qu'il y a des problèmes de
compatibilité ne serait ce que par rapport aux bibliothèques de composants open source récupérées ça
et là sur internet, elles obligent par la même à se remettre en cause à chaque changement
de version. Tous les EDI évoluent quelques soient les éditeurs.

L'informatique est une science jeune, elle a encore des progrès à faire.

Pourquoi les constructeurs d'automobiles sortent de nouveaux modèles ? Pourquoi Airbus fabrique une nouveau
gros porteur A380 alors que boeing reste sur son 747 ? A ces questions, tout le monde optera pour la nouveauté.
Seulement, les voitures comme les avions utilisent une banque d'organe commun (sous traitance) et utilisent le
savoir faire accumulé au fil des années dans l'entreprise sans pour autant tout recommencé à zéro. Il s'agit
de réutilisé ce qui marche quitte à l'améliorer. Le point fort de Delphi est d'être un language orienté objet,
par conséquent il est plus facile de réarchitecturé/refactoré un code existant surtout pour la partie métier.
Les écrans sont un très bel exemple de code récupérable, même s'il en coute quelques widget à remplacer.


Il est tout aussi important de la part des développeurs de faire prendre consciense à leur employeur de
leur utilité dans l'entreprise et des préjudices que cela peut engendrer à moyen ou long terme.

L'écologie a été prise en compte dans l'économie humaine parce que les scientifiques ont parlé d'argent.
Aux développeurs d'en faire de même dans leur domaine.

Facile à dire, mais je vous garantis que certains informaticiens arrivent à leur fins, autrement dit à
convaincre leur direction. Pourquoi pas vous !

[ShaiLeTroll]

Effectivement, cela ne concerne pas que Delphi, pour l'exemple que j'avais cité, je ne suis plus dans la boite, et il y avait une logique d'évolution, juste un peu en retard, ils ont du migrer depuis 3 ans que j'en suis parti ! Surtout que certains boulets parmis les chefs se sont vu mis au placard au profit de certains bien plus compétents ! Comme quoi tout est possible !

L'investissement, ça dépend si tu souhaites conserver l'outil, dans ma boite, le but est de tour faire avec ce qui est appelé "FrameWork Unique Commun", pour le moment en PHP, l'idée qu'un seul outil peut résoudre tous les problèmes, cela me fait toujours marré, alors que souvent un projet peu utiliser plusieurs langage (Delphi, SQL, VBScript, DelphiScript, ...)

Mais en parallèle, on parle quand même de tester Delphi 2009, sur quoi, je suis totalement d'accord, faut juste le temps (que j'aurais si je ne venais pas 2-3 heures sur 8 sur Developpez.com ), et un objectif clair, tester que pour tester, en théorie ça me plait, mais tu tournes vite en rond, alors que pondre un nouveau projet (ce qui est rarissime en Delphi, ils vendent tout en PHP), ça c'est clair, tu sais où tu veux aller et donc tu peux explorer les fonctionnalités pour quelque chose de concret ! c'est plus facile je trouve !

Les Mises à jour ne posent problème que lorsque l'on se laisse déborder, et effectivement comme tu le dit, les bibliothèques externes (payantes ou open-source) qui au final pose problème car plus maintenu c'est parce que l'on se laisse surprendre bêtement alors qu'il faut veiller en permanence sur ses outils.

La principe de ré-utisabilité ne vient pas de l'objet, on faisait déjà des libs en C ... c'est juste que la POO en a fait un principe de base. Par contre, je peux te dire que j'ai des écrans à maintenir qui contiennent tout et n'importe quoi, l'aspect métier et l'aspect technique étant mélangé, imbriqué, absolument pas modulaire, ... c'est récupérable quand c'est bien fait, encore une fois, tout dépend ce que l'on se tape à maintenir, quand tu as 10 développeurs qui se sont succédé, qui n'était pas forcément de vrai pro, qui codait en dépis du bon sens, tant que ça marche ...

Les Développeurs, ce terme regroupe beaucoup de monde, cela va du très très mauvais programmeur au génie suprême en passant par des programmeurs moyens (dont je fais partis) ... déjà faudrait que les développeurs voit plus loin que le bout de leur nez, eh c'est pas évident, parfois tu n'es qu'à peine mieux considérer comme un opérateur de saisi qualifié et parfois tu es le calife, ...
Sinon faut avoir le courage pour dire à son employeur qu'il se trompe !
D'ailleurs, va dire à ton patron que se qu'il développe depuis 10 ans c'est de la merde en tube alors que tu n'es là que depuis 3 mois, tu vas voir la tête des collègues, ... donc tu choisis vite fait, tu te tais, et tu attends que les consciences changent ou que toi-même tu changes de boîte ... ^_^, j'ai testé tous les choix, certains sont plus agréables que d'autres ...

Maintenant, si certains ont de la chance, avec des patrons ouverts et compréhensifs, sans idées arrêtés, bien tant mieux, ce n'est pas le cas de tous ... moi j'en ai connu qui ne jurait que par la simplicité de Windev, considérant que Delphi, fallait y développer trop de chose, ou qui ne voyait que MicroSoft et donc seul C# et SQLServer n'avait droit de cité, alors que Delphi était l'archaisme à éliminer, ... donc quand tu es développeur Delphi, et que ton patron te sors, que ton outil c'est de la merde, eh bien, va lui faire changer d'avis ...