/* Topic des codeurs [7] */

The Uploader · Le 02/07/2012, à 22:57

? Lesquels ?

Et ça te fait des .h redondants à maintenir ?

xapantu · Le 02/07/2012, à 23:10

Ce qui est bizarre c'est plutôt que ces .h ne soient pas générés par le compilateur (ils font comment en Haskell par exemple ?).

The Uploader · Le 02/07/2012, à 23:11

Voilà.

Elzen · Le 03/07/2012, à 00:02

The Uploader a écrit :

Ben la preuve : quel langage a repris le couple .h + .c/.cpp ?

Tous ceux qui utilisent la notion d'interfaces ?

grim7reaper · Le 03/07/2012, à 03:45

The Uploader a écrit :

? Lesquels ?
Et ça te fait des .h redondants à maintenir ?

Objective C.

xapantu a écrit :

Ce qui est bizarre c'est plutôt que ces .h ne soient pas générés par le compilateur (ils font comment en Haskell par exemple ?).

Dépend du backend utilisé par ghc.
- soit il utilise son générateur natif et produit du C--.
- soit il utilise LLVM et produit du bytecode directement.
- soit il produit du C (déprécié), qui sera compilé par gcc il me semble.

The Uploader · Le 03/07/2012, à 06:53

ArkSeth a écrit :

The Uploader a écrit :
Ben la preuve : quel langage a repris le couple .h + .c/.cpp ?
Tous ceux qui utilisent la notion d'interfaces ?

Le C# (ou Java) l'ont sans avoir de fichiers .h

Une API quelconque est une interface de toute façons.

grim7reaper a écrit :

Objective C.

Ah, c'est pas étonnant.

Dernière modification par The Uploader (Le 03/07/2012, à 06:54)

grim7reaper · Le 03/07/2012, à 08:39

The Uploader a écrit :

grim7reaper a écrit :
Objective C.
Ah, c'est pas étonnant.

Oui, vu que c’est un bricolage, avec une syntaxe immonde, par dessus le C.

Elzen · Le 03/07/2012, à 10:10

The Uploader a écrit :

Une API quelconque est une interface de toute façons.

Hmm. Qu'entends-tu par « API » exactement ? (Ça peut s'entendre de plusieurs manières différentes, ce me semble)

The Uploader a écrit :

Le C# (ou Java) l'ont sans avoir de fichiers .h

Bah je n'sais pas en C# (j'n'en ai pas fait assez, et heureusement), mais en Java, le code d'une interface ressemble furieusement au code d'un .h en C : un fichier qui contient uniquement des en-têtes de méthodes, des commentaires de doc d'usage, et éventuellement des déclarations de constantes.
La seule différence, c'est qu'il s'appelle .java comme les autres au lieu d'avoir une extension propre, mais je n'crois pas que ça ait été ça que tu reprochais aux .h, si ?

The Uploader · Le 03/07/2012, à 10:20

ArkSeth a écrit :

The Uploader a écrit :
Une API quelconque est une interface de toute façons.
Hmm. Qu'entends-tu par « API » exactement ? (Ça peut s'entendre de plusieurs manières différentes, ce me semble)

Rien que les méthodes publiques d'une classe, c'est déjà une API. Même pas besoin que ce soit une classe, en fait.

ArkSeth a écrit :

The Uploader a écrit :
Le C# (ou Java) l'ont sans avoir de fichiers .h
Bah je n'sais pas en C# (j'n'en ai pas fait assez, et heureusement), mais en Java, le code d'une interface ressemble furieusement au code d'un .h en C : un fichier qui contient uniquement des en-têtes de méthodes, des commentaires de doc d'usage, et éventuellement des déclarations de constantes.

Pareil en C# sauf que c'est un .cs et que le nom commence par I.
http://msdn.microsoft.com/fr-fr/library … 80%29.aspx

ArkSeth a écrit :

La seule différence, c'est qu'il s'appelle .java comme les autres au lieu d'avoir une extension propre, mais je n'crois pas que ça ait été ça que tu reprochais aux .h, si ?

Non, le reproche est d'avoir à maintenir deux fichiers pour le même code source.

T'as pas un .java et un .h.

Elzen · Le 03/07/2012, à 10:28

The Uploader a écrit :

T'as pas un .java et un .h.

Bah non, vu que les interfaces ont la même extension que les autres : quand tu veux changer un truc dans l'interface, t'as à maintenir deux fichiers .java (ou plus : celui de l'interface pour les changements, et ceux des différentes classent qui l'implémentent. Voire éventuellement aussi des classes qui l'utilisent, d'ailleurs ^^)
Si par contre tu ne retouches qu'au contenu d'une méthode, tu n'as à rectifier que ledit contenu, sans retoucher au fichier d'en-têtes (que ce soit en C ou en Java).

D'où l'intérêt, d'ailleurs, de faire une bonne pré-conception (avec des diagrammes de classes et compagnie), histoire d'avoir des en-têtes qui n'ont pas souvent de raisons de bouger ; l'interface ou le fichier .h, quand tu bosses correctement, c'est ce que tu retouches le moins.

Tiens, d'ailleurs, en parlant d'UML, il est vraiment parti, l'autre ? Depuis quand les trolls se barrent vraiment dès la première fois qu'ils le disent ?

Dernière modification par ArkSeth (Le 03/07/2012, à 10:32)

The Uploader · Le 03/07/2012, à 10:35

ArkSeth a écrit :

The Uploader a écrit :
T'as pas un .java et un .h.
Bah non, vu que les interfaces ont la même extension que les autres : quand tu veux changer un truc dans l'interface, t'as à maintenir deux fichiers .java

Ouais bah c'est nul. Les fichiers d'en-tête, c'est du travail en plus pour faire plaisir au compilateur, et pas un travail intéressant.

ArkSeth a écrit :

Si par contre tu ne retouches qu'au contenu d'une méthode, tu n'as à rectifier que ledit contenu, sans retoucher au fichier d'en-têtes (que ce soit en C ou en Java).

ArkSeth a écrit :

D'où l'intérêt, d'ailleurs, de faire une bonne pré-conception (avec des diagrammes de classe et compagnie), histoire d'avoir des en-têtes qui n'ont pas souvent de raisons de bouger ; l'interface ou le fichier .h, quand tu bosses correctement, c'est ce que tu retouches le moins.

Heureusement certains langages n'ont pas de .h ou équivalent.

Dernière modification par The Uploader (Le 03/07/2012, à 10:41)

Elzen · Le 03/07/2012, à 10:48

The Uploader a écrit :

Ouais bah c'est nul. Les fichiers d'en-tête, c'est du travail en plus pour faire plaisir au compilateur, et pas un travail intéressant.

Okay, donc tu passes à côté d'une tonne d'aspects du trucs, normal…

Pour mémoire, et entre autre caractéristiques, les fichiers d'en-tête (que ce soient les .h ou les interfaces en Java) :

– sont une présentation formelle de la pré-conception (on pourrait tout-à-fait envisager un programme qui te les génère depuis le diagramme de classe, ou réciproquement). Ça peut être plus lisible (beaucoup plus, parce qu'on y met plus d'infos concrètes) qu'un diagramme de classe pour comprendre la structure et les relations du programme.

– sont un accès nettement facilité aux sources (ça te permet, quand tu recherches un bout de code précis, de commencer par regarder où il est dans un fichier beaucoup plus réduit puisque ne comprenant que la charge utile pour cette opération (les en-têtes et documentations des méthodes, sans que tu aies à scroller des tonnes de codes qui ne te servent strictement à rien dans le cas présent)).

– facilitent énormément le travail en équipe (on se met d'accord une bonne fois pour toute sur les fichiers d'en-tête, et ensuite chacun peut prendre un bout du truc à coder dans son coin, pour peu qu'on respecte ce qu'on a défini formellement au départ, on est sûr d'avoir une intégration qui se fera naturellement (et si on se rend compte en codant que quelque chose ne va pas, c'est que ça concerne toute l'équipe, et qu'il faut revoir ça ensemble)

– facilitent énormément le débuggage, puisque ça permet de spécifier clairement, pour chaque méthodes, les pré- et post-conditions et compagnie. Faire du TDD sans fichiers d'en-têtes, ç't'un peu comme faire du droit sans code pénal.

En contrepartie de la perte desdits avantages, quand tu n'utilises pas de fichiers d'en-tête, tu as :

– Un petit fichier de moins à retoucher le jour où tu te rends compte (si et seulement si ça arrive) que tu as codé comme un goret et que ta préconception n'était pas bonne.

Fichtrement mieux, dis donc

The Uploader · Le 03/07/2012, à 10:55

ArkSeth a écrit :

– sont une présentation formelle de la pré-conception (on pourrait tout-à-fait envisager un programme qui te les génère depuis le diagramme de classe, ou réciproquement). Ça peut être plus lisible (beaucoup plus, parce qu'on y met plus d'infos concrètes) qu'un diagramme de classe pour comprendre la structure et les relations du programme.

Ruby :
Class.methods
rdoc..

ArkSeth a écrit :

– sont un accès nettement facilité aux sources (ça te permet, quand tu recherches un bout de code précis, de commencer par regarder où il est dans un fichier beaucoup plus réduit puisque ne comprenant que la charge utile pour cette opération (les en-têtes et documentations des méthodes, sans que tu aies à scroller des tonnes de codes qui ne te servent strictement à rien dans le cas présent)).

Ruby :
Class.methods
rdoc..

ArkSeth a écrit :

– facilitent énormément le travail en équipe (on se met d'accord une bonne fois pour toute sur les fichiers d'en-tête, et ensuite chacun peut prendre un bout du truc à coder dans son coin, pour peu qu'on respecte ce qu'on a défini formellement au départ, on est sûr d'avoir une intégration qui se fera naturellement (et si on se rend compte en codant que quelque chose ne va pas, c'est que ça concerne toute l'équipe, et qu'il faut revoir ça ensemble)

Pas forcément. Je travaille en équipe, et en Ruby on n'a pas eu de problème de consistance/coordination.

ArkSeth a écrit :

– facilitent énormément le débuggage, puisque ça permet de spécifier clairement, pour chaque méthodes, les pré- et post-conditions et compagnie. Faire du TDD sans fichiers d'en-têtes, ç't'un peu comme faire du droit sans code pénal.

On dira ça à tous ceux qui font du TDD dans des langages qui n'ont pas de fichiers d'en-têtes :
"Oui bonjour. C'est pour vous dire que vous faites ça n'importe comment."

ArkSeth a écrit :

Fichtrement mieux, dis donc

Yép, carrément.

ArkSeth a écrit :

– Un petit fichier de moins à retoucher le jour où tu te rends compte (si et seulement si ça arrive) que tu as codé comme un goret et que ta préconception n'était pas bonne.

Ça arrive toujours. Ceux qui prétendent le contraire n'ont jamais codé.

Dernière modification par The Uploader (Le 03/07/2012, à 10:56)

Elzen · Le 03/07/2012, à 10:59

The Uploader a écrit :

Ruby :
Class.methods
rdoc..

Étant donné que je ne connais pas Ruby, tu peux développer ?

The Uploader a écrit :

On dira ça à tous ceux qui font du TDD dans des langages qui n'ont pas de fichiers d'en-têtes :
"Oui bonjour. C'est pour vous dire que vous faites ça n'importe comment."

De ce que j'ai pu constater, généralement, ils font… la même chose qu'un fichier d'en-tête, mais présenté autrement (genre, un document à part qui n'est pas du code mais qui présente les mêmes informations (juste de manière moins formelle)).

Franchement, j'suis dans une phase Western, alors je n'résiste pas :

Le monde des développeurs se divise en deux catégories : ceux qui savent bosser proprement, et ceux qui se plaignent d'avoir un copier-coller à faire entre deux fichiers.

Dernière modification par ArkSeth (Le 03/07/2012, à 11:00)

The Uploader · Le 03/07/2012, à 11:03

ArkSeth a écrit :

The Uploader a écrit :
Ruby :
Class.methods
rdoc..
Étant donné que je ne connais pas Ruby, tu peux développer ?

- liste des méthodes de la classe (même pas besoin de l'instancier).
- documentation (elle peut être générée à partir de commentaires)

ArkSeth a écrit :

The Uploader a écrit :
On dira ça à tous ceux qui font du TDD dans des langages qui n'ont pas de fichiers d'en-têtes :
"Oui bonjour. C'est pour vous dire que vous faites ça n'importe comment."
De ce que j'ai pu constater, généralement, ils font… la même chose qu'un fichier d'en-tête, mais présenté autrement (genre, un document à part qui n'est pas du code mais qui présente les mêmes informations).

rdoc, quoi.

ArkSeth a écrit :

Franchement, j'suis dans une phase Western, alors je n'résiste pas :
Le monde des développeurs se divise en deux catégories : ceux qui savent bosser proprement, et ceux qui se plaignent d'avoir un copier-coller à faire entre deux fichiers.

Le monde se divise en deux catégories : ceux qui ont séparé deux choses qui n'ont rien à voir, à savoir les en-têtes pour la compilation et la documentation, et les sagouins qui mélangent les deux.

(le topic revit! )

Dernière modification par The Uploader (Le 03/07/2012, à 11:10)

Elzen · Le 03/07/2012, à 11:23

The Uploader a écrit :

- liste des méthodes de la classe (même pas besoin de l'instancier).
- documentation générée à partir de commentaires

Ouais, donc, en gros, un fichier d'en-tête, mais généré depuis le code plutôt que fait en amont, c'est ça ?

Donc la même chose, à ceci près que ça perd tous les avantages de propreté, de connaissance du code, de balisage de chemin et compagnie…

The Uploader a écrit :

Le monde se divise en deux catégories : ceux qui sont resté au C/C++/Java/Objective C, soit aux années 1990, et les autres, qui ont séparé deux choses qui n'ont rien à voir parce que c'est plus propre : les en-têtes pour la compilation, et la documentation.

Le bon vieux troll du « ça s'appuie sur un truc qui existe depuis longtemps, donc c'est forcément périmé »
Faudrait que tu suives l'évolution de certains trucs plus en détail, toi (genre, j'ai suivi récemment une conférence d'un spécialiste en bases de données qui nous montrait que les concepts développés dans les années 80 étaient toujours en vigueur et que c'étaient toujours eux qui faisaient marcher le truc).

Franchement, soyons sérieux deux minutes : quand tu codes, tu commences bien par définir les en-têtes de méthodes et la documentation qui les accompagne, avant d'attaquer le contenu de ces méthodes, rassure-moi ? La seule différence entre ça et les fichiers d'en-tête, c'est que tu rajoutes le contenu dans un même fichier comme un gros bourrin au lieu de garder le squelette bien proprement à part ?

(À la limite, ceux qui sont trop feignants pour maintenir deux fichiers séparés utilisent déjà un EDI pour automatiser d'autres trucs, nan ? Bah l'EDI en question doit (en tout cas, si c'est Vim ou Emacs, il y a de fortes chances) disposer d'un plugin pour générer automatiquement le fichier d'en-tête à partir du fichier d'implem, pour continuer à coder cradement sans avoir à râler contre la propreté )

(.h files : « An elegant weapon for a more civilized time. »)

The Uploader · Le 03/07/2012, à 11:32

ArkSeth a écrit :

Donc la même chose, à ceci près que ça perd tous les avantages de propreté, de connaissance du code, de balisage de chemin et compagnie…

Non. C'est tout aussi propre.

ArkSeth a écrit :

Le bon vieux troll du « ça s'appuie sur un truc qui existe depuis longtemps, donc c'est forcément périmé »

Où ça ? (relis mon message )

ArkSeth a écrit :

Franchement, soyons sérieux deux minutes : quand tu codes, tu commences bien par définir les en-têtes de méthodes et la documentation qui les accompagne, avant d'attaquer le contenu de ces méthodes, rassure-moi ?

1.nom des objets bien choisis
2.code qui s'auto-documente au mieux (genre, tu met en privé ce qui n'a pas de sens à être public...)
3.documentation

ArkSeth a écrit :

(.h files : « An elegant weapon for a more civilized time. »)

Mélanger la doc et les en-têtes pour le compilateur (alors que ça devrait, oh je sais pas moi, être au plus proche du code.. genre des commentaires avant les méthodes, ce qui permettra aussi leur utilisation par le générateur de doc'..) :
"You maniacs ! You blew it up! Damn you ! Damn you all to hell !"

Dernière modification par The Uploader (Le 03/07/2012, à 11:42)

Dr Le Rouge · Le 03/07/2012, à 11:43

Vu que le topic respawn, je relance une question.

Sinon, les .h c'est pratique pour mettre les commentaires doxygen

Dernière modification par Dr Le Rouge (Le 03/07/2012, à 11:44)

Elzen · Le 03/07/2012, à 12:54

À première vue j'n'ai pas grand chose à redire à ton découpage, mais il faudrait que je regarde le truc un peu plus en détail pour répondre plus précisément

The Uploader a écrit :

Où ça ? (relis mon message )

Trop tard, j'ai quoté ta grosse absurdité avant que tu l'édites

The Uploader a écrit :

Mélanger la doc et les en-têtes pour le compilateur

Toi, tu mélanges la partie déclarative (le « contrat » de la programmation par contrat) avec l'implémentation ; ç'n'est guerre mieux.

Le truc à voir, c'est que le fait que le .h (ou que l'interface Java) ait une utilité pour le compilateur est secondaire (une conséquence historique, sans plus) ; son intérêt principal réside dans le fait de séparer proprement la déclaration formelle et structurelle de l'objet, et celle de son développement effectif.

Ça va notamment dans le sens du principe de dépendance inversée : « Abstractions should not depend upon details. Details should depend upon abstractions. »

En déduisant les prototypes de fonctions du code, comme ce que tu as l'air de mettre en avant en Ruby, tu fais dépendre l'abstraction (l'interface, au sens humain du terme, c'est-à-dire la manière dont tu peux interagir avec le truc) du détail, puisqu'il faut le fichier destiné à contenir le code pour déterminer ça.

En construisant d'abord un fichier d'en-têtes, que tu vas ensuite reprendre pour faire le fichier de code proprement dit, tu vas faire dépendre les détails de l'abstraction, puisque tu as un squelette clairement défini, dont l'implémentation effective n'est qu'une conséquence (interchangeable, en plus, tu peux faire plusieurs implémentations différentes dont tu peux savoir automatiquement si elles respectent ou pas les pré-requis).

The Uploader · Le 03/07/2012, à 12:59

ArkSeth a écrit :

En déduisant les prototypes de fonctions du code, comme ce que tu as l'air de mettre en avant en Ruby

Euh non, les prototypes sont là aussi...

class Machin
  #prout
  #utilisateur : utilisateur à prouter. Instance de Utilisateur
  def prout(utilisateur) # prototype
  puts "prout à #{utilisateur.to_s}" # implémentation
  end
end

Pour le reste:
What's important is the Interface, not the interface [keyword]

Ce n'est pas la même philosphie que Java, tout simplement. Ce n'est pas pour autant plus sale.

ArkSeth a écrit :

Trop tard, j'ai quoté ta grosse absurdité avant que tu l'édites

Non, regarde mon heure de modif' et l'heure de ton message où tu cites...

Dernière modification par The Uploader (Le 03/07/2012, à 13:08)

Elzen · Le 03/07/2012, à 13:14

The Uploader a écrit :

Non, regarde mon heure de modif' et l'heure de ton message où tu cites...

Bah ouais, j'ai appuyé sur « citer » d'abord, et ensuite j'ai pris un certain temps à rédiger le message. Problem ?

The Uploader a écrit :

Euh non, les prototypes sont là aussi...

Ouais, ils sont là. En vrac en plein milieu du code, donc dépendant du fichier définissant les détails, au lieu d'être une abstraction définie à part et dont le détail dépendrait. Donc non-conforme au DIP.

The Uploader a écrit :

Ce n'est pas pour autant plus sale.

Dire qu'un truc qui ne respecte pas SOLID est aussi propre qu'un truc qui le respecte, je n'suis pas fondamentalement contre, mais tu vas avoir beaucoup de boulot pour redéfinir la propreté

Dernière modification par ArkSeth (Le 03/07/2012, à 13:15)

The Uploader · Le 03/07/2012, à 13:15

ArkSeth a écrit :

Dire qu'un truc qui ne respecte pas SOLID est aussi propre qu'un truc qui le respecte, je n'suis pas fondamentalement contre, mais tu vas avoir beaucoup de boulot pour redéfinir la propreté

J'crois que tu confonds un peu tout là...

Ruby est SOLID.

Dernière modification par The Uploader (Le 03/07/2012, à 13:16)

Elzen · Le 03/07/2012, à 13:17

The Uploader a écrit :

Ruby :
Class.methods
rdoc..

ArkSeth a écrit :

(…) principe de dépendance inversée : « Abstractions should not depend upon details. Details should depend upon abstractions. »
En déduisant les prototypes de fonctions du code, comme ce que tu as l'air de mettre en avant en Ruby, tu fais dépendre l'abstraction (l'interface, au sens humain du terme, c'est-à-dire la manière dont tu peux interagir avec le truc) du détail, puisqu'il faut le fichier destiné à contenir le code pour déterminer ça.
En construisant d'abord un fichier d'en-têtes, que tu vas ensuite reprendre pour faire le fichier de code proprement dit, tu vas faire dépendre les détails de l'abstraction, puisque tu as un squelette clairement défini, dont l'implémentation effective n'est qu'une conséquence (interchangeable, en plus, tu peux faire plusieurs implémentations différentes dont tu peux savoir automatiquement si elles respectent ou pas les pré-requis).

Dernière modification par ArkSeth (Le 03/07/2012, à 13:18)

The Uploader · Le 03/07/2012, à 13:20

Une classe en Ruby est son propre fichier d'en-tête (ou Interface), c'tout.

Rien à voir avec SOLID.

Dernière modification par The Uploader (Le 03/07/2012, à 13:23)

Elzen · Le 03/07/2012, à 13:23

Y a un truc que tu ne comprends pas dans le fait qu'en faisant en sorte que l'en-tête ne soit définie que dans le fichier contenant le détail du code, tu lies les deux de telle sorte que l'abstraction se trouve de facto dépendre du détail auquel elle est donc nécessairement associée ?

Dernière modification par ArkSeth (Le 03/07/2012, à 13:24)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1126 Le 02/07/2012, à 22:57

Re : /* Topic des codeurs [7] */

#1127 Le 02/07/2012, à 23:10

Re : /* Topic des codeurs [7] */

#1128 Le 02/07/2012, à 23:11

Re : /* Topic des codeurs [7] */

#1129 Le 03/07/2012, à 00:02

Re : /* Topic des codeurs [7] */

#1130 Le 03/07/2012, à 03:45

Re : /* Topic des codeurs [7] */

#1131 Le 03/07/2012, à 06:53

Re : /* Topic des codeurs [7] */

#1132 Le 03/07/2012, à 08:39

Re : /* Topic des codeurs [7] */

#1133 Le 03/07/2012, à 10:10

Re : /* Topic des codeurs [7] */

#1134 Le 03/07/2012, à 10:20

Re : /* Topic des codeurs [7] */

#1135 Le 03/07/2012, à 10:28

Re : /* Topic des codeurs [7] */

#1136 Le 03/07/2012, à 10:35

Re : /* Topic des codeurs [7] */

#1137 Le 03/07/2012, à 10:48

Re : /* Topic des codeurs [7] */

#1138 Le 03/07/2012, à 10:55

Re : /* Topic des codeurs [7] */

#1139 Le 03/07/2012, à 10:59

Re : /* Topic des codeurs [7] */

#1140 Le 03/07/2012, à 11:03

Re : /* Topic des codeurs [7] */

#1141 Le 03/07/2012, à 11:23

Re : /* Topic des codeurs [7] */

#1142 Le 03/07/2012, à 11:32

Re : /* Topic des codeurs [7] */

#1143 Le 03/07/2012, à 11:43

Re : /* Topic des codeurs [7] */

#1144 Le 03/07/2012, à 12:54

Re : /* Topic des codeurs [7] */

#1145 Le 03/07/2012, à 12:59

Re : /* Topic des codeurs [7] */

#1146 Le 03/07/2012, à 13:14

Re : /* Topic des codeurs [7] */

#1147 Le 03/07/2012, à 13:15

Re : /* Topic des codeurs [7] */

#1148 Le 03/07/2012, à 13:17

Re : /* Topic des codeurs [7] */

#1149 Le 03/07/2012, à 13:20

Re : /* Topic des codeurs [7] */

#1150 Le 03/07/2012, à 13:23

Re : /* Topic des codeurs [7] */

Pied de page des forums