• # Intérêt ?

    Posté par  (site Web personnel) . Évalué à 10 (+9/-0).

    Le site ne donne pas d'argument en faveur de SDLang ou en défaveur de JSON ou YAML. Quel problème cherche-t-il à corriger, quelle amélioration apporte-t-il ?

    J'ai parcouru les exemples, je n'ai rien vu d'attirant au premier regard. Je me suis arrêté au format des dates, en me demandant pourquoi l'auteur n'avait pas repris le format ISO…

    Forcément, le XKCD qui s'impose : https://xkcd.com/927/

    • [^] # Re: Intérêt ?

      Posté par  . Évalué à 1 (+2/-2).

      Peut-être pousser par Oracle pour attaquer les utilisateurs par la suite pour récupérer des sous ?

    • [^] # Re: Intérêt ?

      Posté par  . Évalué à -1 (+1/-4).

      Je n'en vois aucun en pratique non plus. Par contre j'en vois un stratégique : diviser pour mieux régenter.

    • [^] # Re: Intérêt ?

      Posté par  (site Web personnel) . Évalué à 7 (+5/-1).

      Je vois les avantages suivants:

      • on peut mettre des commentaires (json puxor) ;
      • la syntaxe ne dépends pas de l'indentation (yaml puxor) ;
      • c'est lisible (xml puxor).

      Effectivement le choix du format des dates non iso est curieux.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Intérêt ?

        Posté par  . Évalué à 7 (+6/-0).

        Toml

        • [^] # Re: Intérêt ?

          Posté par  . Évalué à 3 (+1/-0). Dernière modification le 17/09/21 à 00:14.

          TOML est conçu comme une amélioration de INI (plutôt orienté configuration que sérialisation de données structurées comme JSON)
          C'est vrai qu'il a aussi les bénéfices mentionnés en plus d'être plus facile et bien supporté/intégré par/avec les divers langages.

      • [^] # Re: Intérêt ?

        Posté par  . Évalué à 3 (+1/-0).

        Le format c-style est sympa, mais du coup il est plus faible qu'un DSL fais en groovy/ruby

        • [^] # Re: Intérêt ?

          Posté par  . Évalué à 2 (+0/-0).

          ça se présente comme un dérivé human-friendly de XML : c'est déjà un DSL agnostique de tout langage de programmation, un peu comme recfiles…

      • [^] # Re: Intérêt ?

        Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

        Je trouve que JSON5 est une meilleure solution alors.

        Notamment, je trouve que les attributs sont une mauvaise idée. Cela donne deux manières de renseigner une valeur, avec les dérives qui vont avec et la complexité pour naviguer dedans (cf Xpath).

        JSON et YAML représentent de la donnée universelle qu'on peut directement manipuler dans les types de bases de tous les langages de haut-niveau : dictionnaire, liste, etc. Tu parse et après tu oublie le format pour utiliser les API natives du langage.

        XML requiert une API spécifique pour manipuler les éléments, leurs enfants et leurs attributs. C'est un vrai fardeau à l'usage. SDLang a la même API DOM avec element.getTagAttribute, element.getTagValue, element.getTag, etc.

        En fait, SDLang est à XML ce que le YAML est au JSON, un variante plus facile à rédiger manuellement. Donc c'est bien quand on est payé à la ligne de code.

    • [^] # Re: Intérêt ?

      Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

      C'est pas mieux d'améliorer, si nécessaire, les formats existants plutôt que de complexifier (et de bordelifier) en en rajoutant un ?

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: Intérêt ?

        Posté par  . Évalué à 4 (+2/-0).

        Gérer N versions d'un format pas forcément compatible plutôt que N formats différents ? (qui n'ont pas prévu de versionement au passage) Ça ne change pas grand chose.

        Mais ça dépend de l'objectif.

        S'il s'agit d'un format d'échange comme l'est json tu as besoin d'avoir pleins de choses qui le gèrent.
        Si c'est le format de configuration de ton logiciel tout le monde s'en fou. Personne ne se pleins que nginx, apache httpd, vim ou autres ont des formats de configuration dédiés.

      • [^] # Re: Intérêt ?

        Posté par  . Évalué à 3 (+1/-0).

        Que fais-tu du syndrome nih ?

      • [^] # Re: Intérêt ?

        Posté par  (site Web personnel) . Évalué à 3 (+2/-2).

        Pour json c'est faisable (exemple: https://json5.org/).

        Pour xml, il suffit de ne l'utiliser que là où il est strictement nécessaire (documentation).

        Pour yaml, la seule amélioration possible c'est de le mettre à la poubelle.

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Intérêt ?

          Posté par  . Évalué à 4 (+2/-0).

          json5 est très peu supporté donc tu ne peux pas t'en servir pour une api publique par exemple et les parseurs ne peuvent pas déduire le format (il faut des heuristiques qui valent ce qu'elles valent). Si demain json++ sort avec des choix différents de json5, ça va devenir compliqué par exemple.

  • # inconsistances

    Posté par  . Évalué à 2 (+1/-1).

    Quand je vois :

    // Tags may contain certain non-alphanumeric characters
    this-is_a.valid$tag-name
    

    OK, mais quand juste après on a :

    // Namespaces are supported
    renderer:options "invisible"
    physics:options "nocollide"
    

    ça me pose souci parce-que les balises peuvent contenir n'importe quel caractère …y compris les deux points non ? Au passage, je me demande quel est l'équivalent de cet exemple, avec les espaces de noms, en XML !

    De même, bien plus tôt on a :

    // Anonymous nodes are supported
    "This text is the value of an anonymous node!"
    

    c'est sympa, mais pareil : les balises pouvant contenir n'importe quels caractères, pourquoi ce ne serait pas une balise avec une valeur vide ? Et sinon, dans quel cas a-t-on des valeurs qui flottent comme ça ?

    • [^] # Re: inconsistances

      Posté par  . Évalué à 3 (+1/-0).

      ça me pose souci parce-que les balises peuvent contenir n'importe quel caractère …y compris les deux points non ?

      Non, c'est dans la doc :

      Names and namespaces are identifiers.
      […]
      An SDLang identifier starts with a unicode letter or underscore () followed by zero or more unicode letters, numbers, underscores (), dashes (-), periods (.) and dollar signs ($).


      les balises pouvant contenir n'importe quels caractères

      Non des lettres et quelques caractères et pas les espaces du coup.

      • [^] # Re: inconsistances

        Posté par  . Évalué à 2 (+0/-0).

        Ah, pas vu cette doc. Mais du coup, ça fait moins que JSON et YAML mais bon ça se positionne par rapport au XML.
        Y a des restrictions sur les attributs ?

        Et le coup des valeurs sans identifiants ? (nœuds anonymes…)

  • # très mal nommé

    Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

    Le nom du projet (son acronyme) entre en conflit avec la vénérable SDL.

    l'azerty est aux dispositions ce que subversion est aux SCMs

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.