Moonz a écrit 3621 commentaires

Je pense qu'il faut prendre "devient" comme "en train de devenir"...

Sur le fond, la situation n'est pas vraiment la même:
- Si demain MS fait que IE ne lise plus que les pages standard -> tous les sites passent aux standards.
- Si demain Firefox ne fonctionne plus qu'avec les pages standards -> "Firefox sai dla merde" et firefox retombera à 1% de parts de marché (et encore...)

Sur la forme, je suis d'accord: deux poids, deux mesures, ça pue

Sur la même page:
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/#s(...)
Ce qui je lirais plutôt comme "n'utilisez text/html que pour être compatible avec la vieille soupe infâme"...

> Je crois que je n'ai pas saisie ce que tu entendais pas ton "flot de la page",
Comment peux tu manipuler l'arbre DOM du menu depuis la page ?
Comment fais tu si tu veux que les règles de style de ta page s'appliquent à ton menu ? (hors d'inclure le même fichier CSS à la fois dans le menu et dans la page)
Comment fais tu pour un menu dont la taille change dynamiquement (cas des menus "déroulants") ?

La balise object, ce n'est qu'une grosse boite. Ça peut suffire pour des choses basiques, mais c'est franchement limité par rapport au modèle d'une forêt de boites qui prévaut en XHTML/CSS.

Non, les ">" dont là pour dire "fils direct". En les enlevant, le style s'appliquera au h de niveau deux ou supérieur:
[h]Premier niveau, ne s'applique pas[/h]
[section]
[h]Second niveau, s'applique[/h]
[section]
[h]Troisième niveau, s'applique[/h]
[section]
[h]Quatrième niveau, s'applique[/h]
...

Soit dit en passant, ton "body" est inutile (tout section est un descendant de body). Le mien sert justement à déterminer le "section" de premier niveau.

(en xpath, mon expression serait //body/section/h, tandis que la tienne est //body//section//h,//body//section//h//section//h, qui ne répond absolument pas au problème...)

Grrr, un mauvais C-z a dû traîner, une parenthèse de mon message a sauté:
si tu envoies ton fichier via HTTP, le doctype ne suffit pas, il faut aussi envoyer le bon Content-type (le type donné par HTTP étant prioritaire). Tu peux mettre le doctype que tu veux, tant que tu envoies du text/html, ça reste de la soupe. Par contre, quand tu envoies du xml (plusieurs types mime possibles), là, tu dis "je fais du xhtml", et effectivement firefox te gueule dessus si tu fermes une balise de travers...

> Ouai, mais seulement ce genre de truc est un cauchemar à styler. Comment styler les titres de deuxième niveau par exemple, et uniquement de deuxième niveau ?


body > section > h {
...
}

Non ? (en tout cas, je trouve ça joli ;))

>> Ben oui, il y a la solution du doctype mais les dev win sont trop con pour l'utiliser donc on choisi autre chose.
> C'est quoi cette argumentation de merde,

Ça s'appelle du bon sens. Quand dans un script ruby la première ligne est:
#!/usr/bin/env python
l'interpréteur python me sort une erreur quand j'essaie d'exécuter ce script avec un ./script. Normal. Manquerait plus que l'OS détecte que c'est une syntaxe ruby et qu'il fasse un exec(ruby) pour "faciliter la vie au développeur"...

HTML 5 n'est pas le successeur de XHTML 1 mais de HTML 4, qui n'était pas un dialecte XML... Pas d'abandon donc, puisque HTML n'a jamais eu de syntaxe XML..

Par contre, un nouveau XHTML qui prendrait les bonnes idées de HTML 5 serait le bienvenu...

> , d'ailleurs, les seuls moments où on a recours au pointeur de char, c'est des "const char*", donc pas pour les manipuler.
Haem...
http://cplusplus.com/reference/iostream/istream/getline.html
http://cplusplus.com/reference/iostream/streambuf/xsgetn.htm(...)

> en C++, on n'utilise pas de chaine de charactères en char*
Tu veux dire, comme avec std::fstream ? :)

Tu as raison, j'ai posté trop vite.
Mea culpa, la prochaine fois je tournerai ma langue 7 fois avant de cliquer sur envoyer (je dis ça à chaque fois...)

> Non. On n'a pas besoin de trier un ensemble pour en extraire les éléments uniques.
Oui, mais avec une complexité (algorithmique, s'entend) beaucoup plus grande...

Bon, on va répéter pour ceux au fond qui n'ont pas écoutés:
Le but est (entre autre) d'être directement et nativement compatible au niveau ABI (et quasi immédiatement au niveau API) avec GObject (c'est un projet Gnome, après tout), même pour le modèle objet. Tu peux m'expliquer comment tu fais ça avec D ? L'ABI de D est très proches de celle du C++, et n'a rien à voir avec celle de Vala/GObject qui est du pur C.

Pour faire encore plus clair, supposons que je fasse en Vala puis en C++ ou en D une classe Foo avec une méthode bar. Maintenant, je veux appeler cette méthode dans un programme C (disons, pour simplifier, que j'ai déjà une instance f). Si ça a été codé en vala:
foo_bar(FOO(f)); (fonctionne de la même manière que gtk_window_set_title(GTK_WINDOW(w), "Hello, world"); )
en C++:
_ZN3Foo3barEv(f); (je ne l'ai pas inventé, c'est le nom qu'a donné G++ à la méthode...)
Et encore, ce code dépend de l'ABI C++ du compilateur, et j'ai considéré que la fonction n'était pas virtuelle. Vois tu où se situe Vala, maintenant ?

Pour rentrer dans le troll, j'avais regardé du côté de D il y a quelques années lorsqu'il venait à peine d'être libéré, et c'était à l'époque assez intéressant. Mais maintenant qu'aujourd'hui on a GCJ, j'ai du mal à voir l'intérêt.

> L'avantage est que le compilateur est un front-end à gcc et qu'il peut donc être disponible sur un grand nombre de plate formes.
Vala transformant en code C pour le faire avaler à GCC, je pense qu'on peut difficilement faire plus portable :)

C'est le cas d'à peu près tous les langages (sauf peut être Brainfuck ;)), et je n'ai jamais dit que C++ était une sous merde inutilisable que seul un barbare sous l'emprise de substances illicites utiliserait, hein (c'est "l'approche windows" qui a choqué ? ce n'était pas dans un but péjoratif, c'était juste pour illustrer que philosophiquement, il y avait un gouffre énorme entre Objective-C et C++). Tout ce que mon message dit, c'est que l'Objective-C est au C++ ce que kate est à KDevelop. Je conçois et respecte que l'on puisse aimer les IDEs-usine-à-gaz, mais d'autres aiment bien les éditeurs simples et sobres.

Non, le code généré par Vala est très lisible et extrèmement proche de ce qu'aurait écrit un développeur C+GObject (certains argueront que ce n'est justement pas lisible, mais là n'est pas le troll :))

> Et qu'est ce que ça change ?
100% et immédiatement compatible avec le C et l'énorme paquet de code GObject existant, le tout avec une syntaxe un peu moins lourde

> Créer un langage propre et qui marche est loin d'être trivial...
Justement, c'est plus proche d'un préprocesseur que d'un vrai langage...

Étant "fanboy" (comme le mot est à la mode ici) d'Objective-C, je vais vaguement essayer d'expliquer l'intérêt de ces langages.
En un mot: C++ est une couche très épaisse au dessus du C. Objective-C est une couche très fine au dessus du C. Les implications:
- se retrouvent en termes de complexité. Ajouter une couche Objective-C au dessus d'un compilateur C est trivial (pour l'anectode, un développeur du projet Étoilé a réecrit la couche logique (pas syntaxique) de l'objective-c en deux jours!). Ajouter le ++ au C, par contre, est un réel cauchemar pour l'implémenteur (une histoire de grammaire qui n'est plus LALR). Pour l'utilisateur, cela se ressent fortement. Le créateur du C++ a dit quelque chose du genre "je ne m'attend pas à ce que qui que ce soit comprenne le langage dans sa totalité" (c'est assez proche de la philosophie Perl: on ajoute du bloat et du bloat syntaxique et chaque développeur apprend son propre sous-langage - mis à part qu'en C++, ce sous langage est relativement commun). Personnellement, je suis (très) loin d'être une lumière, mais j'ai réussit à me coder un binding générique Objective-C <-> Python pleinement fonctionnel en quelques jours (et j'ai très eu d'expérience en Objective-C derrière moi) - en ramant plus sur la partie Python que Objective-C. Après, je ne débattrai pas plus longuement sur l'intérêt de la simplicité, la littérature abonde là dessus.
- Une équivalence entre le C et l'Objective-C. Le C++ est vaguement capable de réutiliser ce qui est fait en C (donc C => C++ - et encore, il y a des cas assez rares où un code C ne compile pas en C++ - simple exemple: en C, tu peux avoir une variable "class". C++ réserve ce mot clef). En Objective-C également, la réutilisation du code C est à 100% possible (et sans les cas rares du C++) mais l'inverse est également vrai: même en n'ayant qu'un compilateur C sous la main il est possible de réutiliser des librairies Objective-C. Réutiliser les librairies C++ en C sans compilateur C++ est totalement exclu.
Pour résumer, Objective-C est très proche de l'approche Unix (transparence, simplicité et couche fine) tandis que le C++ est plus proche de l'approche Windows (cacher les détails d'implémentation, préférer la complétude à la simplicité, la "couche épaisse" n'étant qu'un corollaire de ces deux derniers points)
Vala, quant à lui, serait un Objective-C avec une couche un peu plus épaisse, ce qui lui permet d'ajouter des concepts de plus haut niveau et de s'affranchir de concepts qui seraient de trop bas niveau au goût de certains développeurs objet. Tout en restant à 100% équivalent au C, simple et transparent. Un excellent compromis à mon goût (même si la syntaxe C#-like me sort par les trous de nez :))

C# ne vise pas à être "une couche au dessus du C" (qu'elle soit fine ou épaisse) et n'a donc rien à voir avec les autres que tu as cités. Il serait beaucoup plus proche du Java.

Maintenant, Vala et Objective-C font ils doublons ? Oui et non. De loin, ils poursuivent les mêmes objectifs, mais de près:
- On peut mettre directement du C dans du code Objective-C. Objective-C, en fait, n'étend que légèrement le C pour les définitions et les déclarations de classes/méthodes/fonctions (à la limite, Objective-C aurait pu être fait à coup de directives du préprocesseur. D'ailleurs, il me semble que la première implémentation d'Objective-C n'était qu'un préprocesseur), tandis que Vala est un langage à part entière.
- Objective-C cible le C et les développeurs C. Vala cible GObject et des développeurs de "haut niveau" (garbage collector par exemple. Je sais, il y en a aussi en Objective-C, mais vu son échec retentissant...)
Ces deux différences suffisent, AMHA, à justifier l'existence des deux en parallèle.
Un petit bémol pour Vala, toutefois, est le fait qu'il s'appuie sur GObject dont le modèle objet est singulièrement limité comparé à l'Objective-C: pas de categories, impossibilité de surharger une méthode, réflexion limitée.

Bon, c'est pas tout ça, mais j'étais censé bosser aujourd'hui moi, pas mouler... :-/

> Donnez des technologies ou réflexions qu'a apporté Ubuntu. Bonne chance.
Upstart
En même temps, au vu du résultat, je sais pas trop si on peu appeler ça un "apport" -->[]

Ha non, ça c'est pas un bug, c'est une fonctionnalité...

En même temps, c'est un peu un bug, hein...
(http://eikke.com/kde4-reviewed/5/)

> quoi de plus destabilisant qu'une fonction qui prend un paramètre dont le nom est pas très explicite et dont on connais pas le type...
Normalement, les types possibles des paramètres et des valeurs de retour doivent être documentés. Après, c'est certain que le langage n'interdit personne à mal coder, hein :)
> la doc est fouilli... trouvé quelque chose n'est pas toujours simple. Comparé avec la doc de Qt ou de Java
La doc de Qt, je ne sais pas. J'en ai entendu beaucoup de bien, même si je l'ai jamais essayée moi même. Mais honnêtement, ma maigre expérience de Java a été un cauchemar au niveau documentation en ligne (peut être que la doc intégrée aux IDEs est meilleure...). Honnêtement, je vois très mal comment préférer http://java.sun.com/j2se/1.4.2/docs/api/ à http://docs.python.org/
> - beaucoup de reste d'un langage pas objet à la base
Pardon ???
Il va falloir epliquer plus profondément que ça. Quand tu sais que même les modules, les classes et les fonctions sont des objets, je vois mal ce qu'il te manque ;)
>- de même, j'ai tendance a oublier les self....
Ça m'a pris quelques mois pour attraper le réflexe, mais c'est vrai que c'est dur, au début ;)
> Bref, en fait la seul chose que j'aimerais ça serait d'avoir un typage obligatoire
Tu enlèves là un gros avantage du langage. Même si dans, disons, 80% des cas, le type est connu à l'avance, le typage fort (ou, le typage de python est fort) dynamique est carrément jouissif dans les 20% autres cas (surtout quand tu penses au nombre de lignes supplémentaires que ça aurait pris dans un langage à typage statique). Certaines choses que j'ai faites proprement en Python en quelques lignes grâce à ce typage dynamique m'auraient prises plusieurs fichiers et une bonne centaine de lignes en Java.

> Ou alors Python va-t-il s'améliorer avec Py3k ?
Pour l'autocompletion, un truc asez intéressant va arriver dans Python 3k: la possibilité d'annoter les fonctions. Par exemple, les définitions suivantes deviennent valide en Python 3000:

def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):

def haul(item: Haulable, *vargs: PackAnimal) -> Distance:

Par défaut, l'interpréteur n'en fait rien, mais on peut très bien l'utiliser comme:
- documentation
- dire quels types sont supportés
- vérification de type à l'aide d'un décorateur

Après, il faut bien sûr que les IDEs en tirent partie. Mais c'est là une autre histoire :)

Et ruby répond à ton problème du self ;)

> Bof, ca suppose que t'interdise dans le langage certaines constructions tout de même
J'ose espérer que c'est la JVM qui interdit à une applet d'écrire dans mon $HOME et que c'est pas "une construction du langage" Java. Sinon, cela voudrait dire qu'il est possible d'écrire du code malicieux en byte-code...

> il peut facilement monter à 30 voire 40
Enfin, faut déjà être un sacré trolleur :)

> Attention, il s'agit d'une syntaxe Python, utilisez des espaces plutôt que des tabulations !
Là, va falloir que tu m'expliques la relation de causalité entre "syntaxe python" et "utiliser des espaces"

> Mon navigateur retient les mots de passe (généralement aléatoires)
Et le jour où:
- tu changes de navigateur
- les devs de ton navigateur décident que "pour des raisons de sécurité, les mots de passe ne sont conservés que deux semaines"
- tu perds ton .mozilla (ou .kde, ou .opera ou je sais pas quoi) suite à une fausse manip
tu l'as un peu dans l'os...

Sans compter les problèmes que ça pose si tu accèdes à internet à partir de deux postes différents, où tu dois synchroniser ta base de mots de passe

> Personnellement je suis réticent à avoir une identité unique partout
Je vais répéter, encore une fois (ça commence à lasser, mais je n'abandonnerai pas): LE grand avantage de OpenID, s'il ne fallait en retenir qu'un seul, c'est sa très grande flexibilité (pour l'utilisateur. Pour le programmeur, c'est vachement moins marrant, il faut l'admettre, mais là n'est pas la question ;)). Tu peux très bien avoit n identités "visiblement" (de l'extérieur) différentes mais qui en fait (pour le fournisseur d'identité) sont les mêmes, de la même manière que foo@gmail.com, foo+bar@gmail.com et foo+spam@gmail.com sont la même adresse (et tu peux imaginer des alias plus sophistiqués que ça !). Donc tu peux très bien te logguer une seule fois auprès de ton fournisseur pour n identités (une pour linuxfr, une pour lj, une par forum,...)