/* Topic des codeurs [7] */

Elzen · Le 03/07/2012, à 16:25

The Uploader a écrit :

Euh, tu as fait plus que ça, tu as prétendu que le langage n'y était pour quasiment rien :
ArkSeth a écrit :
Donc tu reconnais bien que le problème réside uniquement dans le fait que tu as la flemme de devoir faire ça à la main, et que donc ça vient moins du langage que du fait que tu n'aies pas encore la fonction adaptée dans ton EDI ?
Depuis quand est-il recommandé d'inclure des fichiers source plutôt que des headers en C ?

T'es encore en train de me sortir des trucs qui ne correspondent absolument pas à ce que j'ai dit (genre, où ai-je parlé de ce qui est recommandé ou pas ?)

J'ai simplement dit que le maintient de la correspondance entre les deux peut être automatisée, ce qui est quand même le cas.

Et, le langage n'est effectivement pour rien dans le fait que tu fasses à la main ou que tu automatises un truc qui peut être fait des deux manières.

The Uploader a écrit :

T'es obligé de maintenir des .h si t'es un minimum sérieux.
Dans un langage haut niveau, cette obligation disparaît.

Java n'est pas assez de haut niveau, selon toi ?

Parce que jusqu'à preuve du contraire, tu y es aussi obligé de maintenir la concordance entre les interfaces et leurs implémentations…

The Uploader a écrit :

Je n'ai pas à chercher de plugin pour l'indentation, ni à l'activer, quel que soit l'IDE.

Juste parce que c'est une fonctionnalité courante, et donc activée par défaut. Prends n'importe quel truc spécifique à un type de programmation donnée, la moitié des EDI ne le proposeront pas par défaut. Ça n'voudra pour autant pas dire que c'est une misère

xapantu a écrit :

Tiens, je ne sais pas ce que tu t'es mis à manger ArkSeth, mais tu es très énergique ces temps ci !

Il fait moins chaud, ça réveille

cervo · Le 03/07/2012, à 16:31

'tain, vous bossez pas les mecs pour avoir le temps de vous fighter comme ça??

Dr Le Rouge · Le 03/07/2012, à 16:40

Carrément… À part un post de xapantu et un à moi pour protester contre leur flood, la page précédente ne contient que leur débat

Elzen · Le 03/07/2012, à 16:42

Vous savez bien ^^

Dr Le Rouge · Le 03/07/2012, à 17:12

Y'a quelqu'un qui veut que tu retournes au lit ?

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

ArkSeth a écrit :

Java n'est pas assez de haut niveau, selon toi ?

Y'a des .h en Java ?

J'y comprends plus rien, moi.

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

ArkSeth a écrit :

Parce que jusqu'à preuve du contraire, tu y es aussi obligé de maintenir la concordance entre les interfaces et leurs implémentations…

On en a parlé il y a quelques posts, et il suffisait de lire la ligne suivante…

The Uploader · Le 03/07/2012, à 17:33

Java t'oblige à faire des Interfaces dès que tu veux ré-utiliser du code proprement ?

Non.

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

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

Et (à ma connaissance) aucun langage à part Python ne t'oblige à indenter ton code ; il n'empêche que quand tu veux faire les choses un minimum proprement, c'est ce que tu fais.

valAa · Le 03/07/2012, à 17:43

Euh... c'est "propre" de faire une interface en java pour chaque classe ? O_o

Dernière modification par valAa (Le 03/07/2012, à 17:44)

The Uploader · Le 03/07/2012, à 17:47

ArkSeth a écrit :

Et (à ma connaissance) aucun langage à part Python ne t'oblige à indenter ton code ; il n'empêche que quand tu veux faire les choses un minimum proprement, c'est ce que tu fais.

Ne pas faire de .h ou d'interface (au sens Java) n'empêche pas d'être propre dans les autres langages qui ne le requiert pas ou n'ont pas la notion d'interface au sens Java..

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

valAa a écrit :

Euh... c'est "propre" de faire une interface en java pour chaque classe ? O_o

C'est le principe de la programmation par contrat : préconception → rédaction d'interfaces documentées qui servent à la fois à la généricité (tu peux changer la classe réalisant effectivement le truc sans avoir à retoucher ton code ailleurs) et à spécificer ce que devra faire l'implémentation → codage de la classe implémentant cette interface.

The Uploader a écrit :

Ne pas faire de .h ou d'interface (au sens Java) n'empêche pas d'être propre dans les autres langages qui ne le requiert pas ou n'ont pas la notion d'interface au sens Java..

D'un autre côté, moi je ne te cause que de C et de Java, hein.

C'est toi qui veut impérativement comparer ça avec ton ruby-chéri, façon Hibou.

Se plaindre des .h parce qu'on envisage les choses avec une vision de typage dynamique, c'est un peu comme se plaindre de l'absence d'objet en Lisp : hors sujet.

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

ArkSeth a écrit :

C'est toi qui veut impérativement comparer ça avec ton ruby-chéri, façon Hibou.

C'est ce que j'ai pris en tant qu'exemple au début, c'tout. Puis c'est ce que je connais le mieux.

ArkSeth a écrit :

Se plaindre des .h parce qu'on envisage les choses avec une vision de typage dynamique, c'est un peu comme se plaindre de l'absence d'objet en Lisp : hors sujet.

Ah. Faut surtout pas critiquer le C chéri si on l'utilise pas.

valAa · Le 03/07/2012, à 17:57

ArkSeth a écrit :

valAa a écrit :
Euh... c'est "propre" de faire une interface en java pour chaque classe ? O_o
C'est le principe de la programmation par contrat : préconception → rédaction d'interfaces documentées qui servent à la fois à la généricité (tu peux changer la classe réalisant effectivement le truc sans avoir à retoucher ton code ailleurs) et à spécificer ce que devra faire l'implémentation → codage de la classe implémentant cette interface.

Je vois pas le rapport. Les contrat peuvent se trouver dans les classes.
Une interface en java sert à faire du pseudo héritage multiple, du duck typing, ok, mais là... un bon design (fut il par contrat) ne demande pas du tout d'écrire une interface par classe, ou alors java c'est encore plus pénible que ce que je pensais.

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

valAa a écrit :

Je vois pas le rapport. Les contrat peuvent se trouver dans les classes.

C'est ce que je me tue à dire depuis le début..

Elzen · Le 03/07/2012, à 18:06

valAa a écrit :

Une interface en java sert à faire du pseudo héritage multiple

Une interface peut être utilisée pour ça, mais sa fonction de base est de rendre l'abstraction indépendante des détails de son implémentation (voir par exemple, dans les classes de base, les différentes implémentations de l'interface List).

The Uploader a écrit :

C'est ce que j'ai pris en tant qu'exemple au début, c'tout. Puis c'est ce que je connais le mieux.

Ouais, sauf que comme tu l'as démontré toi-même, ç'n'est pas un truc qui s'utilise de la même façon.

The Uploader a écrit :

Ah. Faut surtout pas critiquer le C chéri si on l'utilise pas.

Je ne pense pas que s'il y ait une personne ici à considérer comme un adorateur inconditionnel du C, ce soit moi

Mais la question primordial, pour une critique constructive, est de savoir si tu envisages bien la chose de la manière dont elle est pensée ou pas.
Moi qui ne connais absolument pas le Ruby, je pourrais très bien prendre tel ou tel aspect et tirer une bardée de boulets rouges dessus sous prétexte que ça me semble totalement abscons, simplement parce que j'apréhende ce comportement avec une logique fondamentalement différente de celle qu'il faudrait.
Les .h n'apportent effectivement pas grand chose par rapport au ruby, mais c'est le simple fait de se ramener au ruby pour envisager les .h qui n'a pas de sens, puisque les deux sont basés sur des concepts différents.

Les fichiers d'en-tête sont fichtrement utiles quand ils sont envisagés d'une certaine manière, et chiants quand ils sont envisagés autrement ; tout comme les pointeurs, l'héritage multiple, les exceptions, les annotations, ou tout autre élément spécifique à une manière donnée de programmer.

Ç't'en partie pour ça qu'il y a autant de langages différents, d'ailleurs.

valAa · Le 03/07/2012, à 18:14

ArkSeth a écrit :

valAa a écrit :
Une interface en java sert à faire du pseudo héritage multiple
Une interface peut être utilisée pour ça, mais sa fonction de base est de rendre l'abstraction indépendante des détails de son implémentation (voir par exemple, dans les classes de base, les différentes implémentations de l'interface List).

Implémentations de List qui, comme par hasard, héritent également d'une autre classe.
your argument is invalid.

edit: je passe sur la citation tronquée en plein milieu de la phrase, hein...

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

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

valAa a écrit :

Implémentations de List qui, comme par hasard, héritent également d'une autre classe.

Ùh ? On n'doit pas causer de la même API :s

Sinon, tu peux voir aussi les différents écouteurs d'événements en AWT/Swing, qui n'héritent souvent que d'Object et n'implémentent aucune autre interface (d'où l'existence des classes abstraites XXXAdapter, implémentations vides de ces interfaces, qui servent à n'avoir à redéfinir que la méthode qu'on veut ; c'est moche, mais ça prouve que ce n'est pas pensé dans une logique d'héritage multiple)

valAa a écrit :

edit: je passe sur la citation tronquée en plein milieu de la phrase, hein...

Bah en fait, j'essaye encore de comprendre l'histoire du duck typing…

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

tshirtman · Le 03/07/2012, à 18:19

au fou…

valAa · Le 03/07/2012, à 18:23

ArkSeth a écrit :

valAa a écrit :
Implémentations de List qui, comme par hasard, héritent également d'une autre classe.
Ùh ? On n'doit pas causer de la même API :s

J'sais pas, je regarde là http://hg.openjdk.java.net/jdk8/jdk8-ga … java/util/

Sinon, tu peux voir aussi les différents écouteurs d'événements en AWT/Swing, qui n'héritent souvent que d'Object et n'implémentent aucune autre interface (d'où l'existence des classes abstraites XXXAdapter, implémentations vides de ces interfaces, qui servent à n'avoir à redéfinir que la méthode qu'on veut ; c'est moche, mais ça prouve que ce n'est pas pensé dans une logique d'héritage multiple)

Oui faire de l'héritage multiple, ou du type erasure, ou du duck typing... (ou un garbage collector :-P) ok...
L'interface est un moyen (que j'aime pas mais ça c'est personnel) en java de réaliser certaines conception, ok.
Mais je vois toujours pas où l'on peut conclure qu'il faut une interface par classe (et donc un fichier de déclaration sans implémentation par classe), pour un bon design. Qui fait ça d'ailleurs ?

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

The Uploader · Le 03/07/2012, à 18:25

Je pensais pas faire un troll aussi réussi.

N'empêche que la principale utilité que je trouve aux en-têtes en C (voir toute l'API d'un coup, en dehors de pouvoir y définir des strucs/ifdef/pragma/bidules_autres), ne me les rend pas utile au point de regretter leur absence (ainsi que celle des interfaces à la java) en Ruby/Python/langageX.

Après hein, dans le contexte du C, celui qui inclut des sources au lieu de .h fait les choses à l'envers, j'veux bien être clair que je n'ai jamais dit le contraire.

ArkSeth a écrit :

Bah en fait, j'essaye encore de comprendre l'histoire du duck typing…

J'ai jamais vraiment compris tout ce que ça impliquait avant de tester en fait. Quand tu viens du C# (le Java de MS), ça fait un choc (bon ça parmi d'autres trucs en Ruby et propre aux langages dynamiques, mais c'est le choc principal).

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

tshirtman · Le 03/07/2012, à 18:32

Tiens on peut utiliser l'api de google drive pour faire de l'ocr… c'est cool ça…

http://stackoverflow.com/questions/1131 … cific-file

Elzen · Le 03/07/2012, à 18:40

valAa a écrit :

J'sais pas, je regarde là http://hg.openjdk.java.net/jdk8/jdk8-ga … java/util/

Regarde là, c'est plus lisible.

Les différentes implémentations de l'interface List (les principales sont Vector, ArrayList et LinkedList) héritent de la classe AbstractList, qui est le premier niveau d'implémentation de l'interface List. Cette classe hérite elle-même de AbstractCollection, qui est le premier niveau d'implémentation de l'interface Collection, dont hérite l'interface List. Au dessus, il n'y a que Object.

Et ces classent n'implémentent, en plus de ladite ascendance, que les interfaces Serializable et Clonnable, qui sont des trucs un peu spaces parce que ne définissant aucune méthode (une histoire d'aspects, tout ça)

(Bon, LinkedList a juste une super-classe intermédiaire particulière et d'autres interfaces correspondant aux méthodes qu'elle apporte en plus, comme List par rapport à Collection).

Bref, aucune trace d'héritage multiple, juste l'application du concept d'abstraction (les interfaces et les classes ont la même hiérarchie d'héritage chacune de leur côté, l'implémentation réunissant les deux en héritant de la classe implémentant l'interface mère de sa propre interface)

valAa a écrit :

Mais je vois toujours pas où l'on peut conclure qu'il faut une interface par classe (et donc un fichier de déclaration sans implémentation) par classe, pour un bon design. Qui fait ça d'ailleurs ?

Bah en même temps, ce point répondait à ta remarque sur la fonction de base d'une interface ; normal que tu n'y trouves pas la réponse à une autre question.

Après, pour répondre précisément et de façon sourcée à cette question-là, il faudra que je retourne voir dans mes cours de L3, que je n'ai présentement pas sous la main, donc si ça t'intéresse, je te redirai ça d'ici quelques temps.

The Uploader a écrit :

N'empêche que la principale utilité que je trouve aux en-têtes en C (voir toute l'API d'un coup, en dehors de pouvoir y définir des strucs/ifdef/pragma/bidules_autres), ne me les rend pas utile au point de regretter leur absence (ainsi que celle des interfaces à la java) en Ruby/Python/langageX.

Logique, vu que dans ces cas-là, tu appliques d'autres concepts de programmation (enfin, j'espère).

De même, l'avantage d'utiliser des interfaces m'apparaît évident quand je fais du Java ; mais quand je fais du Python, je ne les regrette (presque) pas.

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

Pylades · Le 03/07/2012, à 18:40

Le Rouge a écrit :

Hé les mecs, les mecs !
http://smilies.xserver-x.org/smilies/im … ycares.png

^This

Dr Le Rouge · Le 03/07/2012, à 18:56

tshirtman a écrit :

aux fous…

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1176 Le 03/07/2012, à 16:25

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

#1177 Le 03/07/2012, à 16:31

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

#1178 Le 03/07/2012, à 16:40

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

#1179 Le 03/07/2012, à 16:42

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

#1180 Le 03/07/2012, à 17:12

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

#1181 Le 03/07/2012, à 17:12

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

#1182 Le 03/07/2012, à 17:25

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

#1183 Le 03/07/2012, à 17:33

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

#1184 Le 03/07/2012, à 17:42

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

#1185 Le 03/07/2012, à 17:43

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

#1186 Le 03/07/2012, à 17:47

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

#1187 Le 03/07/2012, à 17:50

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

#1188 Le 03/07/2012, à 17:53

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

#1189 Le 03/07/2012, à 17:57

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

#1190 Le 03/07/2012, à 17:59

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

#1191 Le 03/07/2012, à 18:06

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

#1192 Le 03/07/2012, à 18:14

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

#1193 Le 03/07/2012, à 18:18

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

#1194 Le 03/07/2012, à 18:19

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

#1195 Le 03/07/2012, à 18:23

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

#1196 Le 03/07/2012, à 18:25

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

#1197 Le 03/07/2012, à 18:32

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

#1198 Le 03/07/2012, à 18:40

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

#1199 Le 03/07/2012, à 18:40

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

#1200 Le 03/07/2012, à 18:56

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

Pied de page des forums