• [^] # Re: Lignes de code

    Posté par (Mastodon) . En réponse au journal PHP eats rails. Évalué à 3.

    Un vrai framework offre avant tout un cadre de conception, une manière de développer, une façon d'organiser son code, ses fichiers : tu ne met pas tes classes n'importe où

    Ruby offre un cadre de conception, une manière de développer, une façon d'organiser son code, et tu ne mets pas tes classes n'importe où. Un exemple ?

    require 'toto/titi'

    Pourquoi on n'a pas donné un chemin sur le système de fichiers ? Parce qu'on ne met pas ses classes n'importe où, il y a une liste de chemins d'includes, qui sont parcourus dans l'ordre pour trouver tes classes. Les fonctions, les objets, les namespaces, les conventions de nommage, qu'est-ce qui fait partie du langage et qu'est ce qui fait partie du framework ?


    Si tu n'est pas convaincu quand je dis qu'un langage+une bibliothèque forment un framework, essaye de prendre le problème à l'envers, et demande toi si un framework est un langage ou pas. Quand tu prends un bout de code de Rails:

    class Blabla < ActiveRecord::Base
    has_many :clients
    validates_uniqueness_of :name
    accessor :toto
    end

    Ces instructions sont des ajouts du framework. Sauf la dernière qui est une instruction de Ruby. Quelle est la différence avec des mots clés du langage, ou avec une bibliothèque de fonctions ? Qu'est-ce qui empêcherait de faire un compilateur du langage définir par Rails vers un autre langage ? Du point de vue de l'utilisateur, Rails définit un langage avec un peu plus d'instructions qu'en Ruby (d'ailleurs Rails modifie certains objets de la lib standard pour leur rajouter des fonctions), un peu plus de conventions, mais quoi d'autre ?

    Je ne dis pas que PHP, Ruby et Rails ont la même puissance d'expression, mais faire une distinction entre langage et framework est arbitraire.

    Et surtout, un framework est trés souvent orienté vers un type d'application précis.

    C'est aussi le cas de beaucoup de langages.