/* Topic des codeurs [7] */

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

Je ne répète pas l'en-tête, je suis DRY moi.

C'est toujours SOLID.

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

ArkSeth a écrit :

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 ?

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

The Uploader a écrit :

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

Ce serait pas mal d'arrêter le flood d'auto-citations..

Tiens:

lien a écrit :

Dependency inversion principle: depend upon abstractions, do not depend upon concretions
Dependency inversion principle
You probably already know about the values of dependency inversion (aka dependency injection) if you’ve been working in Ruby for a while now. You also probably know that unlike some other languages, there really isn’t a need for DI frameworks because it implements all the necessary tools for good DI at the language level. But in case you didn’t get the memo, I’ll go through a quick example of how dependency inversion can come in handy.
Suppose we have a simple object, like a Roster, which keeps track of a list of people, and we have a RosterPrinter which creates formatted output from that list. Then we might end up with some code similar to what is shown below.
    class Roster  
      def initialize          
        @participants = []  
      end  
      
      def <<(new_participant)  
        @participants << new_participant  
      end  
      
      def participant_names  
        @participants.map { |e| e.full_name }  
      end  
      
      def to_s  
        RosterPrinter.new(participant_names).to_s  
      end  
    end  
      
    class RosterPrinter  
      def initialize(participant_names)  
        @participant_names = participant_names  
      end  
      
      def to_s  
        "Participants:\n" +  
        @participant_names.map { |e| "* #{e}" }.join("\n")  
      end  
    end  
The nice thing about this code is that it separates the presentation of a roster from its data representation, bringing it nicely in line with the single responsibility principle. But the problem with it is that Roster and RosterPrinter are needlessly coupled, which sort of limits the value of separating the objects in the first place. A small change to Roster#to_s() can solve this problem.
    class Roster  
      # other methods same as before  
      
      def to_s(printer=RosterPrinter)  
        printer.new(participant_names).to_s  
      end  
    end  
      
    # usage  
    roster.to_s   
This new code is functionally equivalent to our previous example when called with no arguments, but opens a whole host of new opportunities. For example, we can trivially swap in any printer object we’d like now.
        
    class HTMLRosterPrinter  
      def initialize(participant_names)  
        @participant_names = participant_names  
      end  
      
      def to_s  
        "<h3>Participants</h3><ul>"+  
        @participant_names.map { |e| "<li>#{e}</li>" } +  
        "</ul>  
      end  
    end  
      
    # usage  
    roster.to_s(HTMLRosterPrinter)  
By injecting the printer object into Roster, we can avoid having to resort to something as uncouth as creating a Roster subclass for the sole purpose of wiring up the HTMLRosterPrinter.
Of course, the most common place that talk about dependency inversion comes up is when folks are thinking about automated testing. While Ruby makes it possible to mock out calls to pretty much any object, it’s a whole lot cleaner to pass in raw mock objects than it is to set expectations on real objects.
Dependency inversion can really come in handy, but it’s important to provide sensible defaults so that you don’t end up forcing consumers of your API to do a lot of tedious wiring. The trick is to make it so you can swap out implementations easily, it’s not as important for your code to have no opinion about which implementation it should use. Folks sometimes forget this and as a result their code gets quite annoying to work with. However, Ruby makes it easy to provide defaults, so there is no real reason why this issue can’t be averted.

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

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

On peut continuer à s'auto-quoter longtemps, il n'empêche que ni toi, ni le lien que tu cites ne réponde à cette objection pourtant évidente, qui est que l'absence d'un fichier séparé définissant formellement l'abstraction fait que, dans les faits, il n'est possible de déduire l'abstraction qu'en la récupérant à partir du détail, ce qui implique donc que l'abstraction dépende du détail, ce qui est donc contraire au DIP.

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

Et la rdoc, tu l'ignore depuis le début exprès ?

lien a écrit :

Example

A typical small Ruby program commented using RDoc might be as follows. You can see the formatted result in EXAMPLE.rb and Anagram.

       # The program takes an initial word or phrase from
       # the command line (or in the absence of a
       # parameter from the first line of standard
       # input).  In then reads successive words or
       # phrases from standard input and reports whether
       # they are angrams of the first word.
       #
       # Author::    Dave Thomas  (mailto:dave@x.y)
       # Copyright:: Copyright (c) 2002 The Pragmatic Programmers, LLC
       # License::   Distributes under the same terms as Ruby

       # This class holds the letters in the original
       # word or phrase. The is_anagram? method allows us
       # to test if subsequent words or phrases are
       # anagrams of the original.

       class Anagram

         # Remember the letters in the initial word
         def initialize(text)
           @initial_letters = letters_of(text)
         end

         # Test to see if a new word contains the same
         # letters as the original
         def is_anagram?(text)
           @initial_letters == letters_of(text)
         end

         # Determine the letters in a word or phrase
         #
         # * all letters are converted to lower case
         # * anything not a letter is stripped out
         # * the letters are converted into an array
         # * the array is sorted
         # * the letters are joined back into a string

         def letters_of(text)
           text.downcase.delete('^a-z').split('').sort.join
         end
       end

       tester = Anagram.new(ARGV.shift || gets)

       ARGF.each do |text|
         puts "Anagram! " if tester.is_anagram? text
       end

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

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

T'veux dire le truc qui génère automatiquement la documentation (donc pas l'abstraction en elle-même, mais seulement un truc qui sert à la décrire aux humains) à partir des commentaires présents dans le code, donc à partir du fichier contenant le détail du code, donc en dépendant du détail ?

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

D'abord on a appris que Python et Ruby n'étaient pas SOLID..

Maintenant, une documentation HTML à part, consultable sans le code, avec le formatage qui va bien et des exemples, c'est plus des détails d'implémentation lié au code qu'un fichier d'en-tête pour compilateur ou une interface en Java..

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

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

J'n'ai pas dit que ce n'était nécessairement pas SOLID : il y a peut-être moyen de faire autrement, je n'suis pas un pro de ces langages, je n'fais que regarder ce que tu mets en avant.

Une interface Java et un .h, ce sont des trucs qui contiennent uniquement les en-têtes des méthodes. C'est précisément ça, définir une abstraction : dire (formellement, de façon à ce que ce soit compréhensible autant par le dev qui va devoir s'en servir que par le compilateur/interpréteur qui va pouvoir vérifier « au premier coup d'œil » si le truc qu'on lui passe est conforme ou pas, sans avoir besoin d'essayer de le faire tourner et que ça plante en plein milieu de l'exécution parce que ç'n'est pas conforme) ce que le truc est censé faire, sans avoir à se pencher sur les détails de son implémentation.

Quel que soit l'outil utilisé, si tu as besoin d'aller voir dans le fichier contenant le code pour en tirer les informations requises pour l'utiliser (ce qui est le cas d'une documentation constituée à partir du code lui-même), c'est que tu n'as pas une abstraction clairement définie, mais que la façon dont ça s'utilise dépend du détail de ton implémentation.

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

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

ArkSeth a écrit :

Quel que soit l'outil utilisé, si tu as besoin d'aller voir dans le fichier contenant le code pour en tirer les informations requises pour l'utiliser, c'est que tu n'as pas une abstraction clairement définie, mais que la façon dont ça s'utilise dépend du détail de ton implémentation.

Une rdoc peut être consultée sans le code, une fois qu'elle a été générée...

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

J'ai édité à ce propos, justement.

Admettons : ça veut donc dire que tu as deux fichiers séparés à maintenir, et que les modifs que tu apportes à l'un doivent nécessairement être apportés à l'autre aussi. Oh, comme avec un .h

(J'en reviens donc à ma proposition initiale : si la seule chose qui t'embête dans un .h, c'est de devoir le modifier à la main, cherche-toi un plugin à ton EDI qui va te faire les modifs automatiquement, et puis voilà)

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

ArkSeth a écrit :

J'ai édité à ce propos, justement.
Admettons : ça veut donc dire que tu as deux fichiers séparés à maintenir, et que les modifs que tu apportes à l'un doivent nécessairement être apportés à l'autre aussi. Oh, comme avec un .h

Ben non, tu re-éxecute rdoc, pas besoin de modifier à la main avec tous les risques d'erreurs que ça comporte, et c'est plus rapide.

Et la doc n'est pas mélangée avec tout ce qu'on peut mettre dans un .h et est en dehors d'un fichier .java (un fichier de code), donc c'est mieux.

ArkSeth a écrit :

(J'en reviens donc à ma proposition initiale : si la seule chose qui t'embête dans un .h, c'est de devoir le modifier à la main, cherche-toi un plugin à ton EDI qui va te faire les modifs automatiquement, et puis voilà)

Ben les #ifdef c'est chiant aussi. Donc on les évite et voilà.

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

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

The Uploader a écrit :

Ben non, tu re-éxecute rdoc, pas besoin de modifier à la main avec tous les risques d'erreur que ça comporte, et c'est plus rapide.

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 ?

(De mon point de vue, l'obligation, en C, de définir proprement les en-têtes à part est du même niveau que l'obligation, en Python, d'indenter proprement : ç't'un truc qui, de toute façon, est à faire quand tu veux du code propre, c'est juste que là, le langage s'en sert effectivement)

The Uploader a écrit :

Et la doc n'est pas mélangée avec tout ce qu'on peut mettre dans un .h et est en dehors d'un fichier .java (un fichier de code), donc c'est mieux.

Bah ç'normal, vu que les .h et interfaces Java ont une fonction autre (et autrement plus importante) que de juste fournir les commentaires.
Note au passage que tu peux obtenir le même résultat (générer automatiquement la doc à partir des commentaires du code) en Java également (avec javadoc), et qu'il existe aussi très probablement des outils pour le faire également à partir des commentaires C, si on cherche bien ; c'est juste que ça ne présente qu'une toute petite partie des intérêts d'avoir deux fichiers distincts.

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

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 ?

Le problème est d'avoir à maintenir plusieurs fichiers pour un même code source.
Lancer rdoc, ce n'est pas maintenir un second fichier..

Evidemment aussi en Ruby ou autre langage "haut niveau" on évite les #ifdef et autres du C.

ArkSeth a écrit :

Bah ç'normal, vu que les .h et interfaces Java ont une fonction autre (et autrement plus importante) que de juste fournir les commentaires.

Donc tu mélange bien deux besoins différents : avoir une documentation, et avoir des en-têtes / une interface Java dans un même fichier. Tu ne peux pas consulter la doc' sans le code. Et ça ne te choque pas ?

ArkSeth a écrit :

Note au passage que tu peux obtenir le même résultat (générer automatiquement la doc à partir des commentaires du code) en Java également (avec javadoc), et qu'il existe aussi très probablement des outils pour le faire également à partir des commentaires C, si on cherche bien ;

ArkSeth a écrit :

c'est juste que ça ne présente qu'une toute petite partie des intérêts d'avoir deux fichiers distincts.

On a ces avantages sous une autre forme dans les autres langages, c'est tout.

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

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

The Uploader a écrit :

Le problème est d'avoir à maintenir plusieurs fichiers pour un même code source.
Lancer rdoc, ce n'est pas maintenir un second fichier..

Donc c'est bien qu'il te manque un automatisme, tout simplement.

Sans rdoc, tu aurais à maintenir la doc à la main, et tu râlerais au moins autant (sans doute plus, parce que maintenir la doc, c'est quand même autrement plus prenant (pour rester poli) que de juste changer un en-tête de fonction) ; et l'existence d'un logiciel du type rdoc n'est pas une caractéristique propre à ruby.

Tout ce sur quoi tu es en train de râler, en fait, c'est de ne pas encore utiliser le truc automatique qui va te mettre à jour les fichiers tout seul. C'est donc ta faute, et pas celle du langage

The Uploader a écrit :

Donc tu mélange bien deux besoins différents : avoir une documentation, et avoir des en-têtes / une interface Java dans un même fichier. Et ça ne te choque pas ?

Ça remplit un seul et unique besoin : celui d'avoir un fichier propre et utilisable définissant clairement et formellement le truc et la façon dont ça s'utilise.

Si tu considères que ce sont deux fonctions différentes, vire tous les commentaire de ton code dans un fichier séparé…

(Les commentaires font partie de la déclaration des en-têtes, puisqu'ils servent à définir les pré- et post-conditions et les invariants. Le fichier de documentation généré par javadoc contient très exactement les mêmes informations (les en-têtes des fonctions et les commentaires associés), il s'agit simplement de transformer ça d'une façon qui est un peu plus lisible à l'humain moyen et beaucoup moins à la machine (et accessoirement, qui prend plus de place), mais au niveau contenu, les deux sont rigoureusement identiques)

The Uploader a écrit :

On a ces avantages sous une autre forme dans les autres langages, c'est tout.

Nan, tu as juste d'autres manières, beaucoup plus tarabiscotées, de retrouver à peu près lesdits avantages.

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

The Uploader · Le 03/07/2012, à 14:29

ArkSeth a écrit :

Si tu considères que ce sont deux fonctions différentes, vire tous les commentaire de ton code dans un fichier séparé…

Tu ne peux pas consulter la doc sans le code si tu as les deux dans un .h..
Y'a pas forcément que des prototypes dans un .h...

ArkSeth a écrit :

Nan, tu as juste d'autres manières, beaucoup plus tarabiscotées, de retrouver à peu près lesdits avantages.

Non, on a juste les deux dans le même fichier, ce qui donne exactement les mêmes avantages, plus celui d'avoir moins de maintenance à faire, ni à chercher un plugin pour un IDE (voire à chercher un IDE..), et on génère la doc avec rdoc si y'a besoin de séparer les deux.

ArkSeth a écrit :

Tout ce sur quoi tu es en train de râler, en fait, c'est de ne pas encore utiliser le truc automatique qui va te mettre à jour les fichiers tout seul. C'est donc ta faute, et pas celle du langage

The Uploader a écrit :

Evidemment aussi en Ruby ou autre langage "haut niveau" on évite les #ifdef et autres du C.

Y'a pas forcément que des prototypes dans un .h... Les #ifdef et autres joyeusetés du même genre peuvent devenir un calvaire à maintenir.

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

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

The Uploader a écrit :

Tu ne peux pas consulter la doc sans le code si tu as les deux dans un .h..

Sauf à utiliser un truc qui va te générer la doc standalone à partir du .h comme fait rdoc. Je ne saurais pas te dire lesquels, mais je suis à peu près certain d'en avoir déjà croisé un ou deux.

The Uploader a écrit :

Y'a pas forcément que des prototypes dans un .h...

Certes. D'un autre côté, les #ifdef et compagnie peuvent être foutus dans les .c aussi, hein. La seule spécificité du .h par rapport au reste du code est qu'il reçoit les en-têtes de fonctions.

De la même manière qu'il est possible, en cherchant bien, de foutre du code dans une interface Java, ou de définir une classe et son interface dans le même fichier. Il y a toujours moyen de faire n'importe quoi, quand on veut.

The Uploader a écrit :

Non, on a juste les deux dans le même fichier, ce qui donne exactement les mêmes avantages, plus celui d'avoir moins de maintenance à faire, ni à chercher un plugin pour un IDE (voire à chercher un IDE..), et on génère la doc avec rdoc si y'a besoin de séparer les deux.

Tu perds précisément les avantages de la séparation : l'indépendance des deux, la possibilité de faire plusieurs implémentations distinctes totalement interchangeables (dans le cas de plusieurs implémentations, tu dois faire les modifs sur tous les fichiers concernés ; avoir une interface commune ou un .h te permet de te rendre compte d'éventuels problèmes à ce niveau dès la compilation plutôt que d'avoir le truc qui crashe à l'exécution sans que tu t'y attendes), etc.

Le fait de faire générer la doc automatiquement est indépendant du fait d'utiliser un fichier séparer pour les en-têtes ou pas ; utiliser des en-têtes séparées commentées te permet « juste », à ce niveau, d'avoir l'info directement accessible dans un fichier utile plutôt que de devoir fournir et consulter la doc séparément (ça n'empêche pas de le faire, mais ça permet de s'en dispenser efficacement au moment où tu en as besoin)

Quant au problème de la recherche d'IDE pour satisfaire tes exigences personnelles en matière d'automatismes, elle se pose à partir du moment où tu commences à coder, elle aussi de façon indépendante à cet aspect-là en particulier.

The Uploader a écrit :

Y'a pas forcément que des prototypes dans un .h... Les #ifdef et autres joyeusetés du même genre peuvent devenir un calvaire à maintenir.

Cf le début de mon message : les #ifdef et compagnie sont un aspect bien distinct de l'existence des .h…

Dr Le Rouge · Le 03/07/2012, à 15:03

Hé les mecs, les mecs !

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

ArkSeth a écrit :

Tu perds précisément les avantages de la séparation : l'indépendance des deux

Tu copie/colle tes prototypes dans ton .h dès qu'il y a une modif'. Superbe indépendance.

ArkSeth a écrit :

, la possibilité de faire plusieurs implémentations distinctes totalement interchangeables

Ah, je peux pas faire ça en Ruby ? première nouvelle !

ArkSeth a écrit :

(dans le cas de plusieurs implémentations, tu dois faire les modifs sur tous les fichiers concernés ; avoir une interface commune ou un .h te permet de te rendre compte d'éventuels problèmes à ce niveau dès la compilation plutôt que d'avoir le truc qui crashe à l'exécution sans que tu t'y attendes),

Oui bon, tu es juste contre les langages dynamiques..

ArkSeth a écrit :

etc.

Mais encore ?

ArkSeth a écrit :

Quant au problème de la recherche d'IDE pour satisfaire tes exigences personnelles en matière d'automatismes, elle se pose à partir du moment où tu commences à coder, elle aussi de façon indépendante à cet aspect-là en particulier.

En Ruby je n'ai pas de .h à maintenir, donc je n'ai pas ce problème, ni tous les autres problèmes potentiels d'un fichier d'en-tête du langage C.

Maintenant c'est vrai qu'on pourrait remplacer tous les langages haut niveau par du C, et combler les manques avec des plugins pour IDEs.
Wait...

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

Elzen · Le 03/07/2012, à 15:32

The Uploader a écrit :

Tu copie/colle tes prototypes dans ton .h dès qu'il y a une modif'. Superbe indépendance.

Dès qu'il y a une modif dans la loi, le gouvernement doit changer sa manière de la faire appliquer ; pourtant le pouvoir exécutif est quand même indépendant du pouvoir législatif.

On est sur ce type d'indépendance, là : le fichier d'en-tête détermine ce qui doit être, le fichier de code détermine la façon dont ce sera. Tu peux tout-à-fait mélanger les deux si ça te chante ; c'est juste moins propre.

The Uploader a écrit :

Ah, je peux pas faire ça en Ruby ? première nouvelle !

Je ne vois pas où j'aurais prétendu que ce n'est pas possible… par ailleurs, tu as coupé la citation au mauvais endroit, la partie entre parenthèses était caractéristique de ce que je voulais dire par là.

(Mais au cas où tu ne l'aurais pas remarqué, parce que tu as l'air d'avoir du mal avec ce concept : je n'essaye absolument pas d'enfoncer le Ruby, hein. Je parle des concepts, indépendamment de leur implémentation pratique. C'est quand même curieux, ces gens qui tapent sur un langage pour un point donné, puis s'indignent quand on leur répond sur ce point précis que notre réponse taperait sur leur langage favoris à eux… sur le principe, on dirait les trolls d'un certain pro-Ada )

The Uploader a écrit :

Oui bon, tu es juste contre les langages dynamiques..

Ç'n'est pas ce que j'ai dit non plus.

Le typage dynamique est une problématique à part, qui effectivement apporte des contraintes à ce niveau ; parfois il est adapté (et donc, il faudra perdre l'avantage de vérif avant l'exécution, ce qui effectivement réduit en partie l'intérêt des fichiers d'en-têtes séparés), parfois il ne l'est pas, comme tout.

Mon propos est simplement de rappeler que les fichiers d'en-tête ont un intérêt en eux-mêmes, autre que « pré-requis de compilation ». Ils apportent notamment une certaine propreté d'organisation qu'on ne peut pas retrouver si on s'en prive. Je ne dis pour autant pas qu'il faudrait les utiliser tout le temps ; il arrive dans pas mal de cas que les aspects pratiques amènent à raisonner autrement. Cependant, il y a aussi pas mal de cas dans lesquels c'est largement mieux de faire avec, et ils sont loin d'être un problème en eux-mêmes, quoi qu'ils imposent (comme toute démarche de propreté du code) une maintenance supplémentaire (qui s'avère, lorsque bien utilisée, tout de même profitable)

The Uploader a écrit :

Mais encore ?

Confer notamment les différents points que j'ai évoqué plus tôt (avantages au niveau de la lisibilité, facilitation du travail en équipe et de la démarche de test). J'n'ai pas non plus la prétention de connaître tous les arguments en faveur de tel ou tel procédé.

The Uploader a écrit :

En Ruby je n'ai pas de .h à maintenir, donc je n'ai pas ce problème, ni tous les autres problèmes potentiels d'un fichier d'en-tête du langage C.

Tu utilises vraiment le même IDE, configuré de la même façon, pour tous les langages différents que tu utilises ?

The Uploader a écrit :

Maintenant c'est vrai qu'on pourrait remplacer tous les langages haut niveau par du C, et combler les manques avec des plugins pour IDEs.
Wait...

Bonjour la caricature -_-

Le Rouge a écrit :

Hé les mecs, les mecs !

T'pourrais arrêter de sortir ça à chaque fois qu'on a une conversation intéressante ?

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

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

ArkSeth a écrit :

On est sur ce type d'indépendance, là : le fichier d'en-tête détermine ce qui doit être, le fichier de code détermine la façon dont ce sera. Tu peux tout-à-fait mélanger les deux si ça te chante ; c'est juste moins propre.

je parlais de devoir avoir les mêmes prototypes entre ton .h et ton code source.

ArkSeth a écrit :

Confer notamment les différents points que j'ai évoqué plus tôt (avantages au niveau de la lisibilité, facilitation du travail en équipe et de la démarche de test). J'n'ai pas non plus la prétention de connaître tous les arguments en faveur de tel ou tel procédé.

Ce sont des faux avantages. J'ai les mêmes avantages en Ruby, je n'ai juste pas à copier mes prototypes entre deux fichiers différents, c'tout.

Après, si tu ne veux pas voir le code, tu as un IDE, non ?
Ben il permet sûrement de masquer le code des méthodes.

ArkSeth a écrit :

Mon propos est simplement de rappeler que les fichiers d'en-tête ont un intérêt en eux-mêmes, autre que « pré-requis de compilation ». Ils apportent notamment une certaine propreté d'organisation qu'on ne peut pas retrouver si on s'en prive.

Je ne m'en prive pas, je n'ai juste pas à copier mes prototypes entre deux fichiers différents, c'tout.

ArkSeth a écrit :

Bonjour la caricature -_-

Tu l'as cherché.

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

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

The Uploader a écrit :

je parlais de devoir avoir les mêmes prototypes entre ton .h et ton code source.

Moi aussi.

The Uploader a écrit :

Ce sont des faux avantages.

Scoop : ce n'est pas parce que ton point de vue propre et tes pratiques personnelles font qu'un avantage donné est d'importance minime que c'est un faux avantage.

L'avantage existe, c'est juste que tu n'as pas encore rencontré de cas où il est important (ce qui est logique si tu adoptes essentiellement un point de vue « typage dynamique » dans ta démarche de conception ; un peu comme en pensant essentiellement objet, tu peux répondre de façon tout-à-fait avantageuse à un problème donné sans pour autant voir les avantages qu'aurait apporté une approche fonctionnelle, par exemple)

The Uploader a écrit :

J'ai les mêmes avantages en Ruby

Okay, donc je n'vois pas pourquoi je m'attache à expliquer les concepts et les intérêts en jeu, vu que j'ai juste affaire à un évangéliste pour qui tout ce qui n'est pas la forme encouragée par son langage de prédilection est nécessairement naze.

Hibou, va

The Uploader a écrit :

Tu l'as cherché.

Où ? Comment ?

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

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

ArkSeth a écrit :

Hibou, va

Non sérieusement, le seul avantage d'un .h pour la lisibilité, c'est de ne pas avoir le code, c'est donc éventuellement plus lisible d'un coup d'oeil.

Mais c'est tout..

ArkSeth a écrit :

Où ? Comment ?

En parlant de plugins pour IDE pour cacher les misères du C.

Après hein, le C c'est très bien, mais rien n'est jamais parfait..

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

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

The Uploader a écrit :

Non sérieusement, le seul avantage d'un .h pour la lisibilité, c'est de ne pas avoir le code, c'est donc éventuellement plus lisible d'un coup d'oeil.
Mais c'est tout..

De ton point de vue, et parce que tu regardes ça avec une approche radicalement différente de celle dans laquelle s'exprime l'importance d'un tel truc.

C'est comme si je regardais du code fonctionnel en disant que mouais, bof, ça n'a quasiment aucun avantage par rapport à l'approche objet que j'utilise : bah non, ce n'est pas qu'il n'y a pas d'avantages, c'est que moi je ne les verrais pas, ç'tout.

The Uploader a écrit :

En parlant de plugins pour IDE pour cacher les misères du C.

Okay, donc tu justifies le fait de caricaturer mes propos en te basant sur une caricature de mes propos… Waw.

Pour re-situer : tu t'es plaint de faire à la main un truc qui est automatisable, je t'ai donc suggéré de chercher un outil pour l'automatiser. Le fait que tu doives soit l'automatiser, soit le faire à la main n'est pas plus une « misère du C » que le fait que tu doives, pour qu'un code Python soit correct, soit activer l'indentation automatique, soit indenter à la main, n'est une « misère du Python »…

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

ArkSeth a écrit :

Pour re-situer : tu t'es plaint de faire à la main un truc qui est automatisable, je t'ai donc suggéré de chercher un outil pour l'automatiser.

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 obligé de maintenir des .h si t'es un minimum sérieux.

Dans un langage haut niveau, cette obligation disparaît.

ArkSeth a écrit :

Le fait que tu doives soit l'automatiser, soit le faire à la main n'est pas plus une « misère du C » que le fait que tu doives, pour qu'un code Python soit correct, soit activer l'indentation automatique, soit indenter à la main, n'est une « misère du Python »…

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

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

xapantu · Le 03/07/2012, à 16:50

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

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1151 Le 03/07/2012, à 13:24

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

#1152 Le 03/07/2012, à 13:25

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

#1153 Le 03/07/2012, à 13:26

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

#1154 Le 03/07/2012, à 13:32

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

#1155 Le 03/07/2012, à 13:37

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

#1156 Le 03/07/2012, à 13:39

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

#1157 Le 03/07/2012, à 13:43

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

#1158 Le 03/07/2012, à 13:48

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

#1159 Le 03/07/2012, à 13:50

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

#1160 Le 03/07/2012, à 13:53

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

#1161 Le 03/07/2012, à 13:55

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

#1162 Le 03/07/2012, à 14:03

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

#1163 Le 03/07/2012, à 14:10

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

#1164 Le 03/07/2012, à 14:19

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

#1165 Le 03/07/2012, à 14:29

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

#1166 Le 03/07/2012, à 14:50

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

#1167 Le 03/07/2012, à 15:03

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

#1168 Le 03/07/2012, à 15:03

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

#1169 Le 03/07/2012, à 15:32

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

#1170 Le 03/07/2012, à 15:42

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

#1171 Le 03/07/2012, à 15:48

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

#1172 Le 03/07/2012, à 15:50

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

#1173 Le 03/07/2012, à 16:02

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

#1174 Le 03/07/2012, à 16:16

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

#1175 Le 03/07/2012, à 16:50

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

Pied de page des forums