Discussion :

[souviron34]

bref, sur ce point des appellations, pour Zartan (et Tommy31 ci-dessus) :

cela revient à ce que je disais ailleurs par rapport à l'objet / procédural : ce qui est compréhensible quelle que soit la génération du programmeur c'est la description de la fonctionalité. PAS de l'objet particulier (à moins qu'il ne soit très clair et traversant les ages : "Poste", "Message", "Client", ...) ou du terme technique, qui la plupart du temps est "local", "ponctuel dans le temps" (à moins là encore que ce ne soit très clair ou traversant les ages : "scie", "avion", "moyen de transport", ..).

Imaginez une modélisation objet faite en 1975 dont l'objet central serait "Card" (pour dire "punching card", les cartes perforées disponibles à l'époque). Pour 99.99% des gens d'aujourdhui, personne ne comprendrait de quoi il s'agit .. Cela ne serait pas rattaché à une fonctionalité ou objet identifiable par n'importe qui. Juste pour ceux qui , à l'époque, fonctionnaient avec ce système et ce vocabulaire....

De la même manière, le mot "Toile", ou "embarqué", qui aujourdhui ont un sens, n'en avaient pas il y a 15 ans, et n'en auront vraisemblablement plus dans 15 ans...

Et je ne parle même pas de termes "de modes techniques", comme ce fameux "capcha", "sms", ou autres, qui sont particulièrement liés à une époque et une technologie...

Bref, Zartan, ton exemple est mauvais

[Tommy31]

cela revient à ce que je disais ailleurs par rapport à l'objet / procédural : ce qui est compréhensible quelle que soit la génération du programmeur c'est la description de la fonctionalité.

Je ne vois pas comment il est possible d'exprimer une fonctionnalité sans puiser dans le vocabulaire thématique ou métier du domaine. Surtout dans un processus d'ingénierie des exigences où le client (celui qui formule) est parti prenante.

Imaginez une modélisation objet faite en 1975 dont l'objet central serait "Card" (pour dire "punching card", les cartes perforées disponibles à l'époque). Pour 99.99% des gens d'aujourdhui, personne ne comprendrait de quoi il s'agit .. Cela ne serait pas rattaché à une fonctionalité ou objet identifiable par n'importe qui. Juste pour ceux qui , à l'époque, fonctionnaient avec ce système et ce vocabulaire....

Toujours cette sempiternelle diatribe à l'encontre de l'objet. Le problème soulevé dépasse les paradigmes. Comment nommerais-tu tes structures de données en procédural ?

Note que je partage ton point de vue sur la primauté de la fonctionnalité sur le nommage des choses, mais pas sur ton attitude jusqu'au boutiste.

[souviron34]

Je ne vois pas comment il est possible d'exprimer une fonctionnalité sans puiser dans le vocabulaire thématique ou métier du domaine. Surtout dans un processus d'ingénierie des exigences où le client (celui qui formule) est parti prenante.



Toujours cette sempiternelle diatribe à l'encontre de l'objet. Le problème soulevé dépasse les paradigmes. Comment nommerais-tu tes structures de données en procédural ?

Note que je partage ton point de vue sur la primauté de la fonctionnalité sur le nommage des choses, mais pas sur ton attitude jusqu'au boutiste.

non, je ne suis pas contre l'objet, je suis contre la religion de l'objet..

Quant au vocabulaire, je driais juste que justement, ce que je souligne c'est a contraire l'usage de vocabulaire thématique du métier ou domaine, mais pas de la mode ou d'un raccourci de mode....

[Zartan]

Bref, Zartan, ton exemple est mauvais

Absolument pas, car je n'ai pas besoin de savoir ce qu'est un captcha pour gérer mes bases de données avec Zf.

Et si ça me démange de savoir ce que c'est, je n'ai qu'à consulter la documentation
http://framework.zend.com/manual/fr/zend.captcha.html

L'objet ça permet surtout la réutilisabilité, ce qui est bien pratique car on a pas à réinventer la roue à chaque fois.

[el_slapper]

Absolument pas, car je n'ai pas besoin de savoir ce qu'est un captcha pour gérer mes bases de données avec Zf.

Et si ça me démange de savoir ce que c'est, je n'ai qu'à consulter la documentation :p

http://framework.zend.com/manual/fr/zend.captcha.html

.....et c'est là que je proclame Souviron vainqueur par KO technique. Ah zut, je suis pas arbitre. Mais zend existera encore dans 15 ans? La doc en ligne sera encore trouvable? Tu te focalises sur ta petite personne, là ou Souviron parle de maintenabilité de l'application, y compris longtemps après ton décès(que je te souhaites le plus tardif possible).

Évidemment, toi, tu n'as pas à te poser la question, tu nages dedans. Mais le successeur de ton successeur, quand on ira lui demander de faire évoluer ce vieux programme que personne n'a touché depuis 5 ans et qui date de la décennie précédente, voire de celle d'avant(cas pas d'école du tout, c'est ce que j'ai fait il y a 2 semaines), eh bien il s'arrachera les cheveux.

[Zartan]

C'est comme si tu me disais que je ne peux pas utiliser printf() parce que je ne sais pas ce que fait sqrt().

Le Captcha n'était pas dans mon exemple, uniquement dans l'arborescence des répertoires.

Mais le successeur de ton successeur, quand on ira lui demander de faire évoluer ce vieux programme que personne n'a touché depuis 5 ans et qui date de la décennie précédente, voire de celle d'avant(cas pas d'école du tout, c'est ce que j'ai fait il y a 2 semaines), eh bien il s'arrachera les cheveux.

Au moins il lui en restera quelques un, qu'il perdrait en maintenant un source de 20 000 lignes dont il n'aura pas plus la documentation. Et j'ajouterai que si la doc a été perdue quelque part le boulot n'a pas été fait correctement.

De plus c'est injuste on peut régénérer une partie de la documentation avec phpdoc

En gros défendre ce point de vue ça correspond à défendre le SMS par rapport à une expression écrite correcte sous prétexte qu'on a des contraintes de temps. On parle d'écrire des sources propres pas en termes d'efficacité. Et d'ailleurs l'efficacité est au rendez-vous en terme de maintenabilité quand c'est écrit correctement. Une documentation correcte en fait partie.

Tout ce que j'entends dans ce fil c'est que quand on est obligé de maintenir des programmes non documentés/mal écrits/mal interfacés avec des contraintes de temps et d'efficacité on est obligé d'y aller au sabre. Je suis bien d'accord avec ça, mais ça ne produit pas pour autant des sources propres.

Et pour info voici la doc du C64 Basic, qui aura bientôt 30 ans : http://www.infinite-loop.at/Power64/...C64_BASIC.html

[souviron34]

C'est comme si tu me disais que je ne peux pas utiliser printf() parce que je ne sais pas ce que fait sqrt().

Non parce que ce sont des fonctions de base d'un langage qui, vu son ancienneté et son utilisation de masse, sera encore utilisé dans longtemps...

De plus c'est injuste on peut régénérer une partie de la documentation avec phpdoc

Ce qui présuppose :

1. que ton programme soit en PHP
2. que phpdoc existe toujours

2 assertions qui sortent entièrement du cadre de ce débat..

Tout ce que j'entends dans ce fil c'est que quand on est obligé de maintenir des programmes non documentés/mal écrits/mal interfacés avec des contraintes de temps et d'efficacité on est obligé d'y aller au sabre. Je suis bien d'accord avec ça, mais ça ne produit pas pour autant des sources propres.

Non, ce que tu entends ici, c'est que la notion de "code propre" n'a rien à voir avec le fait de "programmer objet" (alors que tu l'as mentionné (post #35 et suivants)), ni avec le fait d'avoir des centaines de petits fichiers et non un gros...

Mais que appliquer une règle aussi absurde que "on ne doit pas avoir de fichiers de plus de 50 lignes" est une aberration technocratique, et que il arrive qu'il soit bien plus facile de maintenir un code mis dans des très gros fichiers que dispersé dans des centaines de fichiers...



Voilà..

[Zartan]

Ce qui présuppose :

1. que ton programme soit en PHP
2. que phpdoc existe toujours

Zf est écrit en php et phpdoc fait partie de l'installation standard de php, de plus dans le source de zf tout est en place pour générer la doc.

2 assertions qui sortent entièrement du cadre de ce débat..

Absolument pas Zf est un exemple de code propre et Dieu sait que PHP peut être très désagréable à lire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Non, ce que tu entends ici, c'est que la notion de "code propre" n'a rien à voir avec le fait de "programmer objet" (alors que tu l'as mentionné (post #35 et suivants)), ni avec le fait d'avoir des centaines de petits fichiers et non un gros...

Tout ce que j'entend c'est qu'en programmant objet correctement on réduit la taille de ses sources de manière considérable, la réutilisabilité étant le concept clef, et donc forcément on augmente la lisibilité.

Mais que appliquer une règle aussi absurde que "on ne doit pas avoir de fichiers de plus de 50 lignes" est une aberration technocratique, et que il arrive qu'il soit bien plus facile de maintenir un code mis dans des très gros fichiers que dispersé dans des centaines de fichiers...

50 lignes serait absurde en effet, j'ai dit 500 et en aucun cas je n'ai affirmé que c'était une règle mais un objectif.

C'est plus facile pour son auteur à condition qu'il ne fasse que cela mais pour un travail d'équipe les choses sont différentes, sinon les grands projets open source n'auraient que des fichiers de 20000 lignes et non 500 en moyenne comme on l'a vu et ce, non par un effet de mode, mais par souci d'efficacité.

[Tommy31]

Mais zend existera encore dans 15 ans?

Probablement pas, mais cet argument vaut pour un ensemble de choses tellement vaste, que le vocabulaire des termes durables se résumerait à trois fois rien.

La doc en ligne sera encore trouvable?

Des projets comme celui-ci pourraient offrir une pérennisation documentaire.