Author: esj@rezo.net
Date: 2009-08-30 19:01:45 +0200 (dim, 30 aoû 2009)
New Revision: 14437
Log:
Eviter un test est plus efficace qu'une affectation. Et on peut désactiver les traitements par défaut lorsque la valeur ne sert qu'à des comparaisons.
Modified:
spip/prive/login.html
Le 30 août 09 à 19:01, esj@rezo.net a écrit :
Author: esj@rezo.net
Date: 2009-08-30 19:01:45 +0200 (dim, 30 aoû 2009)
New Revision: 14437Log:
Eviter un test est plus efficace qu'une affectation. Et on peut désactiver les traitements par défaut lorsque la valeur ne sert qu'à des comparaisons.
la lisibilité du squelette est aussi un critère qui a sont importance quand on l'écrit.
Et il me semble que l'écriture antérieure était de ce point de vue plus simple.
Cédric
Le 30 août 09 à 19:17, cedric.morin@yterium.com a écrit :
Le 30 août 09 à 19:01, esj@rezo.net a écrit :
Log:
Eviter un test est plus efficace qu'une affectation. Et on peut désactiver les traitements par défaut lorsque la valeur ne sert qu'à des comparaisons.la lisibilité du squelette est aussi un critère qui a sont importance quand on l'écrit.
Et il me semble que l'écriture antérieure était de ce point de vue plus simple.
La lisibilité dépend des usages linguistiques de chacun. Ce qui m'intéresse ici, c'est moins l'efficacité que de montrer que la balise #SET, qui a été introduite pour des raisons d'efficacité, n'apporte pas grand chose sur ce plan, alors qu'elle a amené la notion d'affectation de variable dans l'univers des squelettes qui s'en était dispensé jusqu'alors. Pour les non programmeurs, ne pas rencontrer cette balise lorsqu'ils essayent de maîtriser le langage des squelettes me paraît vivement souhaitable.
Committo,Ergo:Sum
Le 30/08/2009 20:38, Committo,Ergo:sum a écrit :
Le 30 août 09 à 19:17, cedric.morin@yterium.com a écrit :
la lisibilité du squelette est aussi un critère qui a sont importance quand on l'écrit.
Et il me semble que l'écriture antérieure était de ce point de vue plus simple.La lisibilité dépend des usages linguistiques de chacun. Ce qui m'intéresse ici, c'est moins l'efficacité que de montrer que la balise #SET, qui a été introduite pour des raisons d'efficacité, n'apporte pas grand chose sur ce plan
Heu, je suis d'accord avec ce que raconte Cédric, la lisibilité du squelette, c'est important aussi.
Je pense que ça peut se simplifier encore comme ça non ?
[(#ENV**{url}|=={''}|sinon{[(#ENV**{url}|match{^#EVAL{_DIR_RESTREINT_ABS}})]}|oui)
<h3 class="spip"><:login_acces_prive:></h3>
]
--
MM.
Le 30 août 09 à 22:21, Matthieu Marcillaud a écrit :
Le 30/08/2009 20:38, Committo,Ergo:sum a écrit :
Le 30 août 09 à 19:17, cedric.morin@yterium.com a écrit :
la lisibilité du squelette est aussi un critère qui a sont importance quand on l'écrit.
Et il me semble que l'écriture antérieure était de ce point de vue plus simple.La lisibilité dépend des usages linguistiques de chacun. Ce qui m'intéresse ici, c'est moins l'efficacité que de montrer que la balise #SET, qui a été introduite pour des raisons d'efficacité, n'apporte pas grand chose sur ce plan
Heu, je suis d'accord avec ce que raconte Cédric, la lisibilité du squelette, c'est important aussi.
Je pense que ça peut se simplifier encore comme ça non ?
[(#ENV**{url}|=={''}|sinon{[(#ENV**{url}|match{^#EVAL{_DIR_RESTREINT_ABS}})]}|oui)
<h3 class="spip"><:login_acces_prive:></h3>
]
Simplifier ? L'écriture que j'ai adoptée utilise 2 balises différentes (ENV et EVAL) et 3 filtres différents (== ? match).
Celle de Cédric autant de filtres mais 2 de balises de plus (GET, SET), la tienne autant de balises mais 2 filtres de plus.
De ce point de vue, la simplicité est de mon côté.
Committo,Ergo:Sum
Le 30/08/2009 22:21, Matthieu Marcillaud a écrit :
Je pense que ça peut se simplifier encore comme ça non ?
[(#ENV**{url}|=={''}|sinon{[(#ENV**{url}|match{^#EVAL{_DIR_RESTREINT_ABS}})]}|oui)<h3 class="spip"><:login_acces_prive:></h3>
]
Et même :
[(#ENV**{url}|=={''}
|ou{[(#ENV**{url}|match{^#EVAL{_DIR_RESTREINT_ABS}})]})
<h3 class="spip"><:login_acces_prive:></h3>
]
--
MM.
Le 30 août 09 à 20:38, Committo,Ergo:sum a écrit :
Le 30 août 09 à 19:17, cedric.morin@yterium.com a écrit :
Le 30 août 09 à 19:01, esj@rezo.net a écrit :
Log:
Eviter un test est plus efficace qu'une affectation. Et on peut désactiver les traitements par défaut lorsque la valeur ne sert qu'à des comparaisons.la lisibilité du squelette est aussi un critère qui a sont importance quand on l'écrit.
Et il me semble que l'écriture antérieure était de ce point de vue plus simple.La lisibilité dépend des usages linguistiques de chacun. Ce qui m'intéresse ici, c'est moins l'efficacité que de montrer que la balise #SET, qui a été introduite pour des raisons d'efficacité, n'apporte pas grand chose sur ce plan, alors qu'elle a amené la notion d'affectation de variable dans l'univers des squelettes qui s'en était dispensé jusqu'alors. Pour les non programmeurs, ne pas rencontrer cette balise lorsqu'ils essayent de maîtriser le langage des squelettes me paraît vivement souhaitable.
Alors qu'on peut considérer qu'un double test imbriqué incluant un filtre match qui fait appel a une expression régulière est globalement simple à comprendre pour un non programmeur ?
Il me semble que c'est du coupage de cheveux en quatre, et qu'au motif d'éviter un #SET on est obligé de phraser dans sa tête une expression bien compliquée pour comprendre ce que ça fait...
Cédric
Le 30 août 09 à 22:59, Committo,Ergo:sum a écrit :
Le 30 août 09 à 22:21, Matthieu Marcillaud a écrit :
Le 30/08/2009 20:38, Committo,Ergo:sum a écrit :
Le 30 août 09 à 19:17, cedric.morin@yterium.com a écrit :
la lisibilité du squelette est aussi un critère qui a sont importance quand on l'écrit.
Et il me semble que l'écriture antérieure était de ce point de vue plus simple.La lisibilité dépend des usages linguistiques de chacun. Ce qui m'intéresse ici, c'est moins l'efficacité que de montrer que la balise #SET, qui a été introduite pour des raisons d'efficacité, n'apporte pas grand chose sur ce plan
Heu, je suis d'accord avec ce que raconte Cédric, la lisibilité du squelette, c'est important aussi.
Je pense que ça peut se simplifier encore comme ça non ?
[(#ENV**{url}|=={''}|sinon{[(#ENV**{url}|match{^#EVAL{_DIR_RESTREINT_ABS}})]}|oui)
<h3 class="spip"><:login_acces_prive:></h3>
]Simplifier ? L'écriture que j'ai adoptée utilise 2 balises différentes (ENV et EVAL) et 3 filtres différents (== ? match).
Celle de Cédric autant de filtres mais 2 de balises de plus (GET, SET), la tienne autant de balises mais 2 filtres de plus.
De ce point de vue, la simplicité est de mon côté.
La simplicité de compréhension ne se réduit pas à une quantification du nombre d'opérateurs.
Tu semble volontairement faire l'impasse sur le fait que 2 expressions simples sont plus faciles à comprendre et appréhender qu'une grosse expression constituée de sous expressions imbriquées.
Cédric
Le 30 août 09 à 23:55, cedric.morin@yterium.com a écrit :
La simplicité de compréhension ne se réduit pas à une quantification du nombre d'opérateurs.
Cette quantité d'opérateurs ne vise pas seulement ce squelette précis, mais une question plus générale,
qui est posée régulièrement ici ou là (Sedna vient à l'instant d'en repérer une nouvelle occurrence:
http://librefan.eu.org/node/138).
Cette question est: à quoi sert le langage de squelettes de SPIP ?
A ses débuts, ça se présentait comme une manière d'insérer des extraits d'une BD dans une page HTML,
un ensemble de petits trucs syntaxiquement très arbitraires mais vite appris.
Avec le temps, ça devient de plus en plus un langage de programmation complet.
Quelle raison auraient les gens d'apprendre un langage de programmation utilisé par une poignée de personnes dans le monde ?
Absolument aucune. Je prétends que ce langage n'a d'intérêt que s'il reste petit dans son nombre d'opérateurs et de concepts.
On calcule une suite d'éléments d'une BD avec le mot-clé BOUCLE, on désigne un de ces éléments avec le signe # suivi de son nom,
on applique un traitement avec le signe |, voilà qui est clair et concis. En faire plus, a fortiori quand la doc a du mal à suivre,
c'est rebutant pour les nouveaux venus, ceux qui n'ont pas suivi l'évolution depuis plusieurs années.
Committo,Ergo:Sum
Le 31 août 09 à 00:11, Committo,Ergo:sum a écrit :
Le 30 août 09 à 23:55, cedric.morin@yterium.com a écrit :
La simplicité de compréhension ne se réduit pas à une quantification du nombre d'opérateurs.
Cette quantité d'opérateurs ne vise pas seulement ce squelette précis, mais une question plus générale,
qui est posée régulièrement ici ou là (Sedna vient à l'instant d'en repérer une nouvelle occurrence:
http://librefan.eu.org/node/138).
Ca ne nous dit pas grand chose, puisque ce billet concerne explicitement la version 1.8.3, son auteur n'ayant pas expérimenté SPIP depuis.
Cette question est: à quoi sert le langage de squelettes de SPIP ?
A ses débuts, ça se présentait comme une manière d'insérer des extraits d'une BD dans une page HTML,
un ensemble de petits trucs syntaxiquement très arbitraires mais vite appris.
Avec le temps, ça devient de plus en plus un langage de programmation complet.
Quelle raison auraient les gens d'apprendre un langage de programmation utilisé par une poignée de personnes dans le monde ?
Absolument aucune.
Je prétends que ce langage n'a d'intérêt que s'il reste petit dans son nombre d'opérateurs et de concepts.
Et moi je prétends que ça n'est qu'une réponse bancale. Si il se contente de faire cela et rien de plus, et nécessite de repasser en php a la moindre complexité, il n'a guère d'intérêt effectivement, comme le dit l'article
"Les boucles de SPIP (raccourcis PHP) sont assez infernales pour les débutants qui ne pigent rien et pour les experts qui les trouvent encombrantes"
Apprendre un langage qui est limité est effectivement une impasse.
A partir du moment où il manipule suffisamment de concepts pour tout faire, et peut être vu comme une couche d'abstraction il a tout son intérêt, pas seulement pour les débutants.
A ce titre, on arrive aujourd'hui à un seuil ou le langage des squelettes est suffisamment efficace pour permettre de développer vite et bien.
On calcule une suite d'éléments d'une BD avec le mot-clé BOUCLE, on désigne un de ces éléments avec le signe # suivi de son nom,
on applique un traitement avec le signe |, voilà qui est clair et concis. En faire plus, a fortiori quand la doc a du mal à suivre,
c'est rebutant pour les nouveaux venus, ceux qui n'ont pas suivi l'évolution depuis plusieurs années.
Les nouveaux venus calent bien avant cela, sur des choses beaucoup plus simples et évidentes comme le thème par défaut et la difficulté pour le changer, les feuilles de styles, l'apparence de l'espace privé, la gestion des documents ...
Cédric
Le 31 août 2009 à 00:11, Committo,Ergo:sum a écrit :
A ses débuts, ça se présentait comme une manière d'insérer des extraits d'une BD dans une page HTML,
un ensemble de petits trucs syntaxiquement très arbitraires mais vite appris.
Avec le temps, ça devient de plus en plus un langage de programmation complet.
Quelle raison auraient les gens d'apprendre un langage de programmation utilisé par une poignée de personnes dans le monde ?
Absolument aucune. Je prétends que ce langage n'a d'intérêt que s'il reste petit dans son nombre d'opérateurs et de concepts.
On calcule une suite d'éléments d'une BD avec le mot-clé BOUCLE, on désigne un de ces éléments avec le signe # suivi de son nom,
on applique un traitement avec le signe |, voilà qui est clair et concis. En faire plus, a fortiori quand la doc a du mal à suivre,
c'est rebutant pour les nouveaux venus, ceux qui n'ont pas suivi l'évolution depuis plusieurs années.
+1 !
Le 31 août 09 à 00:52, cedric.morin@yterium.com a écrit :
Ca ne nous dit pas grand chose, puisque ce billet concerne explicitement la version 1.8.3, son auteur n'ayant pas expérimenté SPIP depuis.
Je n'ai pas dit que cet article était juste, il est bourré d'idioties; je dis qu'il est révélateur de la mauvaise image de SPIP chez beaucoup.
Je prétends que ce langage n'a d'intérêt que s'il reste petit dans son nombre d'opérateurs et de concepts.
...
Apprendre un langage qui est limité est effectivement une impasse.
Le problème ne se pose pas en ces termes.
Je pense que le langage des squelettes a eu une évolution comparable à celle de HTML.
Au début qqch au but précis et clair, puis des ajouts dans tous les sens débouchant sur un langage trop riche,
dont ensuite la sémantique a été heureusement coupée en deux par le couple HTML4/CSS
et dont la syntaxe a été heureusement homogénéisée par XHTML 1.0.
Je pense que nous devons entamer une évolution similaire, qui ne serait qu'un aspect de l'allègement du noyau avec lequel nous sommes tous d'accord,
en procédant ainsi: dans le noyau limiter la signification de # à l'extraction d'un champs SQL, et déporter toutes les balises SPIP dans des plugins.
Et tant qu'à faire, ne pas passer par l'étape HTML4 mais aller directement à l'étape XHTML, en rendant la syntaxe compatible XML.
Cela redonnera à SPIP sa simplicité originelle accueillante pour les néophytes, qui découvriront ensuite petit à petit le fonctionnement technique
des seuls plugins dont ils auront besoin, plutôt que de devoir tout ingurgiter d'un coup.
On calcule une suite d'éléments d'une BD avec le mot-clé BOUCLE, on désigne un de ces éléments avec le signe # suivi de son nom,
on applique un traitement avec le signe |, voilà qui est clair et concis. En faire plus, a fortiori quand la doc a du mal à suivre,
c'est rebutant pour les nouveaux venus, ceux qui n'ont pas suivi l'évolution depuis plusieurs années.Les nouveaux venus calent bien avant cela, sur des choses beaucoup plus simples et évidentes comme le thème par défaut et la difficulté pour le changer, les feuilles de styles, l'apparence de l'espace privé, la gestion des documents ...
Qu'il y ait d'autres aspects de SPIP que son langage de squelettes qui en rebute certains, c'est vrai, mais ce n'est pas le sujet de la discussion.
Committo,Ergo:Sum
Le 31/08/2009 08:10, Committo,Ergo:sum a écrit :
>> [(#ENV**{url}|=={''}|sinon{[(#ENV**{url}|match{^#EVAL{_DIR_RESTREINT_ABS}})]}|oui)
>> <h3 class="spip"><:login_acces_prive:></h3>
>> ]
> Simplifier ? L'écriture que j'ai adoptée utilise 2 balises différentes (ENV et EVAL) et 3 filtres différents (== ? match).
> Celle de Cédric autant de filtres mais 2 de balises de plus (GET, SET), la tienne autant de balises mais 2 filtres de plus.
> De ce point de vue, la simplicité est de mon côté.
Je suis très surpris de cette remarque ; je comprends ton point de vue sur SET / GET, mais ici, je ne saisie pas : j'ai eu du mal à décrypter le code que tu as déposé, à base d'une écriture |?{' ',xx} qui n'est pas spécialement lisible ; je propose quelque chose qui est plus court à écrire, qui se lit avec une logique qui semble plus clair, et tu dis que ce n'est pas simple. Permets moi d'être quelque peu surpris. Mais passons !
...
Apprendre un langage qui est limité est effectivement une impasse.Le problème ne se pose pas en ces termes.
Je pense que nous devons entamer une évolution similaire, qui ne serait qu'un aspect de l'allègement du noyau avec lequel nous sommes tous d'accord,
en procédant ainsi: dans le noyau limiter la signification de # à l'extraction d'un champs SQL, et déporter toutes les balises SPIP dans des plugins.
Je pousse ton discours un peu loin si je dis que ça revient à supprimer $table_des_traitements ? De cette façon, ne sera retourné par une balise que le contenu réel SQL, auquel on appliquerait ensuite des filtres systématiquement ? tel que [(#TEXTE|traitements_raccourcis)], [(#TITRE|traitements_typo)]… Auquel cas, c'est peut être joli sur le papier, mais je suis vraiment sceptique sur le fait que ça rendrait les squelettes plus lisibles et compréhensibles.
Cela redonnera à SPIP sa simplicité originelle accueillante pour les néophytes, qui découvriront ensuite petit à petit le fonctionnement technique
des seuls plugins dont ils auront besoin, plutôt que de devoir tout ingurgiter d'un coup.
Tu vas finir par dire que je suis mauvaise langue, mais je vais faire une remarque qui finalement va aussi dans le sens de ce que tu avais aussi signalé ailleurs. Je ne suis pas d'accord avec ta remarque qui dit que les néophytes (encore faudrait il savoir ce qu'on entend par là) pourraient découvrir un SPIP à l'eau de rose et tout simple. Justement parce que la plupart se fichent bien du code jusqu'à ce qu'ils aient besoin de modifier quelque chose. Dans ces cas là, ils ont déjà : SPIP, 8 plugins dont 1 jeu de squelettes de contrib plus ou moins paramétrable… De ce fait, quand ils ont à effectuer une modification, c'est effectivement un parcours du combattant : plein de concepts à assimiler d'un coup, et pas uniquement ceux de SPIP et de ses surcharges ; beaucoup découvrent en même temps le PHP, le HTML, le CSS et le JS, et tout ces mélanges leur donnent de gros maux de tête.
Enfin, juste pour que tu précises ton idée, que deviendraient les balises actuelles qui calculent des choses, tel que #LOGO, #URL, #FORMULAIRE, #EXPOSE, et autres ? Je veux dire, par quoi remplacer leur écriture si on va au fond de ce que tu suggères (1 balise = 1 champ SQL) ?
--
MM.
Le 31 août 09 à 10:22, Matthieu Marcillaud a écrit :
je propose quelque chose qui est plus court
C'est plus court parce que tu as connaissance de certains opérateurs, donc des choses de plus à apprendre pour celui qui débarque.
J'aurais pu aussi définir une balise #X qui fait tout le boulot en question, personne n'aurait pu faire plus court que ces 2 caractères;
la brièveté syntaxique n'est pas un argument.
Je pousse ton discours un peu loin si je dis que ça revient à supprimer $table_des_traitements ?
C'est aller trop loin car le néophyte veut pouvoir afficher un extrait de base de données qui contient par exemple des "<" sans avoir à se casser la tête.
J'ai dit que la notion de traitement était un fondamental de SPIP, ça vaut aussi pour les traitements implicites.
Je ne suis pas d'accord avec ta remarque qui dit que les néophytes (encore faudrait il savoir ce qu'on entend par là) pourraient découvrir un SPIP à l'eau de rose et tout simple.
Si tu poses comme a priori que faire un site Web est forcément un parcours du combattant, la discussion est close avant d'avoir commencé !
Enfin, juste pour que tu précises ton idée, que deviendraient les balises actuelles qui calculent des choses, tel que #LOGO, #URL, #FORMULAIRE, #EXPOSE, et autres ? Je veux dire, par quoi remplacer leur écriture si on va au fond de ce que tu suggères (1 balise = 1 champ SQL) ?
Une précision d'abord. Quand je compare le langage des squelettes de SPIP 2.0 avec HTML 3.2, en disant qu'il nous faut inventer l'équivalent du couple XHTML/CSS, cela a plusieurs aspects. Utiliser XHTML sans aucune CSS est extrêment rare, mais ce découpage c'est révélé pertinent. Si je propose qu'on réfléchisse à un découpage équivalent, ce n'est donc pas dans le but qu'on n'utilise plus jamais les "balises SPIP", c'est pour délimiter ce qu'il est indispensable de connaître dans les mécanismes de SPIP, et ce qui sont des constructions souvent utiles mais pas toujours, et qui sont susceptibles d'être remplacées un jour par de meilleures.
Ensuite, à bien y regarder, les balises SPIP sont des cas particuliers d'inclusion de squelettes. Je pense donc que SPIP gagnerait en clarté en trouvant un cadre général pour l'inclusion, syntaxiquement plus concis que l'actuel, et sémantiquement plus facile à appréhender pour le compilateur afin qu'il produise un code aussi efficace qu'aujourd'hui pour chacune. Déjà le #INCLURE est une optimisation bien venue par rapport au <INCLURE> (je parle de leur sémantique, hein), ce dernier n'ayant plus beaucoup de raison d'être à présent (les gains en place ne sont plus beaucoup un souci aujourd'hui, et sont chers payés sur le plan des performances).
Attention, je n'ai pas dit que tout ça était facile et tout tracé, ni qu'il faut mettre à la poubelle les 9/10e de l'existant. Je dis juste que quand un langage devient trop riche, il faut l'éclater en plusieurs parties, conçues de telle manière qu'elles puissent toujours fonctionner ensemble mais être apprises indépendamment.
Committo,Ergo:Sum
* Committo,Ergo:sum tapuscrivait, le 31/08/2009 11:12:
pour chacune. Déjà le #INCLURE est une optimisation bien venue par rapport au <INCLURE> (je parle de leur sémantique, hein), ce dernier n'ayant plus beaucoup de raison d'être à présent (les gains en place ne sont plus beaucoup un souci aujourd'hui, et sont chers payés sur le plan des performances).
Bien.
Mais comment fais-tu pour avoir un squelette avec un cache de 24h qui inclus un squelette avec un cache de 1 minute ?
Actuellement, ça oblige à passer par <INCLURE>
--
RealET
El Monday 31 August 2009 04:17:44 RealET va escriure:
Mais comment fais-tu pour avoir un squelette avec un cache de 24h qui
inclus un squelette avec un cache de 1 minute ?
Actuellement, ça oblige à passer par <INCLURE>
Sans prendre part dans le reste du débat, juste une réponse sur ce
point.
Pour moi, demi-néophyte, ce genre de considérations (pour quelles
inclusions il faut relire le cache et pour lesquelles non) ne devrait
pas être le problème du développeur mais celui du moteur d'inclusions.
Je ne dis pas que c'est trivial avec la structure actuelle du code, je
n'en sais rien. Mais avoir 2 façons différentes d'inclure suivant si la
gestion du cache va être cohérente ou pas, à moins que ce soit expliqué
de façon très très pédagogue (et encore), c'est une de trop.
--
davux
Le 31 août 09 à 11:12, Committo,Ergo:sum a écrit :
la brièveté syntaxique n'est pas un argument.
Et pourtant, quelques messages auparavant, tu justifiais ta proposition par le nombre d'opérateurs utilisés.
Comme d'autres ici, je préfère avoir beaucoup de code lisible plutôt que peu de code illisible.
#SET et #GET m'ont permis de retirer pas mal de code PHP que je traînais depuis les tous débuts de SPIP.
-Nicolas
--
Nicolas HOIZEY
Blog : http://www.gasteroprod.com/
Photos : http://flic.kr/nicolas-hoizey/
Nicolas Hoizey a écrit :
Le 31 août 09 à 11:12, Committo,Ergo:sum a écrit :
la brièveté syntaxique n'est pas un argument.
Et pourtant, quelques messages auparavant, tu justifiais ta proposition par le nombre d'opérateurs utilisés.
Comme d'autres ici, je préfère avoir beaucoup de code lisible plutôt que peu de code illisible.
#SET et #GET m'ont permis de retirer pas mal de code PHP que je traînais depuis les tous débuts de SPIP.
-Nicolas
+1, ces deux simples balises m'ont permis de faire des choses autrement impossibles, et surtout de grandement optimiser mon site en réduisant les appels à la BDD au strict minimum ou presque.
@esj
Sur le troll plus général de la refonte syntaxique de spip, j'ai enfin pu regarder la vidéo d'Avignon (au passage merci pour les bases de travail que tu as posées, c'est un sacré boulot !).
Je réfléchis actuellement sur un embryon de proposition de syntaxe alternative à celle que tu as présentée, parce qu'autant j'abonde dans certains cas (lourdeur), autant j'ai un avis différent sur certains concepts (à commencer par la nécessité de conserver voire étendre le champ de fonctionnalités du langage, particulièrement les balises dont il est question ici).
Je posterai sur spip-dev quand ça ressemblera à quelque-chose.
A bientôt
Simon
Le 1 sept. 09 à 09:45, Simon Camerlo a écrit :
Nicolas Hoizey a écrit :
Le 31 août 09 à 11:12, Committo,Ergo:sum a écrit :
la brièveté syntaxique n'est pas un argument.
Et pourtant, quelques messages auparavant, tu justifiais ta proposition par le nombre d'opérateurs utilisés.
Oui le nombre d'opérateurs, pas le nombre de caractères, merci de ne pas déformer ma pensée: c'est le nombre de concpets sémantiques qui est déterminant, pas le nombre de caractères pour les écrire.
Comme d'autres ici, je préfère avoir beaucoup de code lisible plutôt que peu de code illisible.
#SET et #GET m'ont permis de retirer pas mal de code PHP que je traînais depuis les tous débuts de SPIP.
Remplacer du code d'un langage de programmation bien connu par un code d'un langage de programmation quasi-inconnu n'est pas un progrés en soi, c'est même plutôt un mauvais plan pour ce qui est d'être compris par le plus grand nombre de gens possible. L'enjeu est d'éviter la 2e passe d'exécution (de PHP en l'occurrence), et je prétends que ces deux balises n'étaient pas indispensables pour arriver à ce but.
+1, ces deux simples balises m'ont permis de faire des choses autrement impossibles,
donne un exemple précis.
et surtout de grandement optimiser mon site en réduisant les appels à la BDD au strict minimum ou presque.
L'optimisation est le boulot du compilateur: si un squelette n'est pas performant, il faut essayer de comprendre pourquoi et modifier le compilateur pour que ça profite à tous les squelettes, pas seulement au sien.
@esj
Sur le troll plus général de la refonte syntaxique de spip, j'ai enfin pu regarder la vidéo d'Avignon (au passage merci pour les bases de travail que tu as posées, c'est un sacré boulot !).
Je réfléchis actuellement sur un embryon de proposition de syntaxe alternative à celle que tu as présentée,
J'insiste sur le fait que je n'ai fait que donner un exemple des avantages qu'apporterait une syntaxe acceptée par les éditeurs XML, parmi beaucoup d'autres possibles. Je regrette qu'un troll soit parti sur ce qui n'était qu'un exemple, alors que l'enjeu n'est pas cet exemple.
parce qu'autant j'abonde dans certains cas (lourdeur), autant j'ai un avis différent sur certains concepts (à commencer par la nécessité de conserver voire étendre le champ de fonctionnalités du langage, particulièrement les balises dont il est question ici).
Je ne comprends pas cette remarque: je trouve au contraire que ces balises sont de trop.
Committo,Ergo:Sum
Committo,Ergo:sum a écrit :
J'insiste sur le fait que je n'ai fait que donner un exemple des avantages qu'apporterait une syntaxe acceptée par les éditeurs XML, parmi beaucoup d'autres possibles. Je regrette qu'un troll soit parti sur ce qui n'était qu'un exemple, alors que l'enjeu n'est pas cet exemple.
Je me rends compte que l'ironie est mal passée : c'est évidemment bien plus qu'un troll, c'est un sujet très important.
J'ai bien saisi ta démarche (qui est très saine même si on n'est pas d'accord sur certains points).
J'ai utilisé ce mot à cause de la charge polémique portée par le sujet 
parce qu'autant j'abonde dans certains cas (lourdeur), autant j'ai un avis différent sur certains concepts (à commencer par la nécessité de conserver voire étendre le champ de fonctionnalités du langage, particulièrement les balises dont il est question ici).
Je ne comprends pas cette remarque: je trouve au contraire que ces balises sont de trop.
Oui, c'est pourquoi je dis qu'on n'est pas d'accord sur ce point
Promis, je travaille sur une proposition générale et je poste d'ici quelques semaines sur spip-dev quand ça sera assez mûr.
A bientôt
Simon