Questions sur la demi-finale

Raaa, vous trollez alors que j'ai passé une journée dans un le train, j'ai tout raté.

sam, 28/01/2012 - 12:44 — katagoto

> Je je l'ai dit, les mainframe d'IBM, mais il y a également quelques
> micro-contrôleurs (je pense au MSP430) dont le compilateur ne supporte
> qu'un sous ensemble du C.
Et qui ne supporte pas du tout PHP, what the point?

ven, 27/01/2012 - 21:09 — katagoto

> Un des soucis majeurs de PHP, qui est une de ses forces, c'est qu'on arrive
> rapidement à un résultat visible [...]
Tout est dans le mot résultat et surtout dans la conception que l'on a de ce mot. Mais c'est sûr, si par résultat tu veux dire "arrive à faire un morpion sans trop comprendre comment", oui PHP est plutôt bon pour ça, le problème c'est que ce soit à Prologin ou out there , on code rarement des morpions et surtout on essaye de comprendre ce que l'on fait. J'ai l'impression (ce n'est qu'une impression), que PHP c'est simple pour afficher trois lignes sur un site web dynamique, mais qu'il ne faut pas aller plus loin.

sam, 28/01/2012 - 19:28 — Ekleog

> Et le nom de ces fonctions est très bien choisi. Pourquoi ne pas faire
> "normal", en ajoutant une classe stack ?
Le nommage des fonctions de la bibliothèque standard est juste la preuve que PHP (l'implémentation officielle et donc ce qui est considéré comme la norme) a été développé un peu n'importe comment, c'est sûr qu'ils ont été plus rapide que le WG21 ou que Larry Wall, mais à quel prix ? À vrai dire, je trouve que l'on peut rapprocher cette image des utilisateurs de PHP, ok le code PHP est plus lisible par une personne lambda que le code Perl équivalant, mais à quel prix ? Surtout, est ce important qu'un gros débutant (pour ne pas dire quelqu'un qui veux "coder WOW 6" et non quelqu'un qui veux "apprendre un langage et s'amélioré") comprenne un code dans un langage qu'il ne connaît pas ?

Bon après, comme a dit Stroustrup "people like to hate PHP". Donc, si PHP peut offrir quelque chose (par rapport à Perl, Ruby, etc), j’attends de voir. Mais bon l'argument "c'est simple", il est utilisé pour défendre Windows aussi et (en tant qu'informaticiens raisonnables que nous sommes) on connaît la vérité la dessus...

dim, 29/01/2012 - 16:57 — katagoto

> epsilon012 : je ne vois pas l'intéret de ton message si tu pouvais apporter
> des faits, des arguments et des démonstrations, juste pour avancer.

Je développerai mon propos en trois parties.

Partie I: De l'intérêt de mon message
Je pense qu'avant d'en venir à mon message lui-même, il est important de s'intéresser à la notion du caractère utile entourant celui ci, avant même de se pencher sur son utilité elle-même.

Section 1 : Le conséquentialisme d'une société kantienne
Le devoir utilitaire est intrinsèquement opposé à la vision kantienne dominante dans notre société. Bien que l'intérêt peut être mis en cause, l'intention présente dans le modèle de l'idéal acétique (accepté par Kant) devrait être la cible principale de critique. Mais quelle est donc l'intention de mon message ? Je pense pouvoir affirmer que son intention est de ne pas avoir d'utilité. À voir la réaction de Monsieur Katagoto [1], il semble que cette intention ait été atteinte.
Mais ce n'est pas pour autant que mon message n'a pas d'utilité. En effet l'utilité de mon message est qu'il n'en a pas (justement dirait Jesus Christ). D'ailleurs une phrase introductive annonce clairement la chose :

dim, 29/01/2012 - 13:55 — epsilon012

> Raaa, vous trollez alors que j'ai passé une journée dans un le train, j'ai
> tout raté.
À croire que quelqu'un ait put exprimer la philosophie de Nietzsche sur le nihilisme en une simple phrase.

Section 2 : Nourrir le troll [2]
« What else? »

Georges

Faisons une étude statistique des messages postés en réponse à ce sujet par un utilisateur lambda. Le sujet katagoto s'étant porté lui même volontaire, nous allons étudier ses derniers messages, au nombre de sept :

1. ven, 27/01/2012 - 21:12
2. ven, 27/01/2012 - 21:09
3. ven, 27/01/2012 - 23:05
4. sam, 28/01/2012 - 10:45
5. sam, 28/01/2012 - 12:44
6. sam, 28/01/2012 - 20:40
7. dim, 29/01/2012 - 16:57

Tout d'abord voici un graphe représentant le nombre de ligne (l), mot (w) et caractère (c) de ces messages :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

  l/w/c   ^
20/300/2k |                                      w
          |                                     /|
          |                                    /   
          |                                   +-l c
          |                                  /  |/|
          |         /w-\                    /  -x   
          |        /    -\               /w/ -/  | |
          |       /  /c--\--w--\       -/l/c/    | |
          |      / -/     ---c\ --   -/  /       \   
          |     /-/            \ /lw/  -/         | |
10/150/1k |    //               X\    /           \   
          |   wc                | --c/             | |
          |                    /                   | |
          |                    |                   \   
          |  l\               /                     | |
          |    ---\          /                      \   
          |        \l\       |                       | |
          |           ---\  /                        | |
          |               \l                         \ \w
          |                                           \l\c
          +-------------------------------------------------->
            1lwc   2lwc   3lwc   4lwc   5lwc   6lwc   7lwc  Post

Comme vous l'observez, ce graphe partage clairement une ressemblance avec le test de Rorschach [3]. D'où mon postulat : le sujet essaye d'extérioriser une émotion par ses messages. Ne pouvant pas soumettre le sujet au test pour des raisons de disponibilités. Je pense pouvoir extrapoler la structure du prochain message en devinant la pensée du sujet : il sera structuré comme le message 6. En effet, à ce moment là, en ajoutant le symétrique du graphe, l'on obtient :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

                                         /l/c
             /l                         / /w.
         ---/  \                        | |  .
      /l/       |                       | |   .
  ---/          \                      / /    .
l/               \                     | |     .
                  |                   / /      .
                  \                   | |       .
 wc                | --c\             | |       .
  \\               X/    \           / /         .
   \-\            / \lw\  -\         | |         .
    \ -\     ---c/ --   -\  \       / /           .
     \  \c--/--w--/       -\l\c\    | |           .
      \    -/               \w\ -\  | |            .
       \w-/                    \  -x /             .
                                \  |\|              .
                                 +-l c              .
                                  \ /                .
                                   \|                .
                                    w                .
                                    w                .
                                   /|                .
                                  / \                .
                                 +-l c              .
                                /  |/|              .
       /w-\                    /  -x \             .
      /    -\               /w/ -/  | |            .
     /  /c--\--w--\       -/l/c/    | |           .
    / -/     ---c\ --   -/  /       \ \           .
   /-/            \ /lw/  -/         | |         .
  //               X\    /           \ \         .
 wc                | --c/             | |       .
                  /                   | |       .
                  |                   \ \      .
l\               /                     | |     .
  ---\          /                      \ \    .
      \l\       |                       | |   .
         ---\  /                        | |  .
             \l                         \ \w.
                                         \l\c

Une tête d'extraterrestre ! Avec des antennes en plus… voilà donc la pensée inconsciente de notre sujet… des antennes, le vicieux ! Qui dit extraterrestres dit vert. Qui dit vers dit mouche. Qui dit Jacques a dit lit pas ça.
Mes chers confrères, c'est avec l'expression la plus grave, que je porte donc à votre connaissance la mouchophilie de notre sujet. Le diagnostic est sans appel.

Partie II : De la condition de PHP
La condition de PHP tant en temps que langage que en temps que machine virtuelle et interpréteur est la cible de moultes attaques.

Section 1 : *Take it easy
Une attaque déjà formulé mais étant classé inutiles (bien qu'elle soit intentionnelle) est la non-planification du design du langage. C'est à dire que l'ajout de fonctionnalités se fait de manière sauvage sans aucune conduite [4].
En citant ce papier lui même (chose assez pratique), on voit que j'ai écrit : « PHP […]* est la cible de moultes attaques. ». Or la distance de Levenshtein entre « moultes » et « mouches » n'est que de deux.
Un autre point faible avancé (mais dépourvu d'intérêt) est la complexité caché derrière une apparente facilité [5], pour montrer cela, je vais citer Monsieur Katagoto :

sam, 28/01/2012 - 12:44 — katagoto

> Pour l'instant c'est un tableau, si tu fais \$tbl[42] = 42; là ça devient une
> table de hachage.
Ainsi, qu'un site lambda :

Cours du site du zéro sur PHP

[6]
> Question : Qu'est-ce qu'un array ?
> Bonne réponse : Un tableau
> Explications : Un array est tout simplement un tableau !

Section 2 : Je ne t'abandonnerai jamais
Vraiment.

Partie XLII
Évidement.

Notes :

• [1] Réponse au sujet « Questions sur la demi-finale » le dimanche 29 janvier 2012 à 16:57.

• [2] troll /tʁɔl/ nom commun masculin

  1. (Internet) Internaute postant sur des forums et autres espaces de discussion des messages provocateurs ayant généralement trait à des sujets prompts à susciter des débats houleux.
  2. (Par métonymie) Le sujet du débat lui-même.

  Référence : Wiktionnaire - [3] Wikipedia (fr) - [4] Réponse au sujet « Questions sur la demi-finale » le dimanche 29 janvier 2012 à 14:55, quatrième paragraphe. - [5] Réponse au sujet « Questions sur la demi-finale » le dimanche 29 janvier 2012 à 14:55, troisième paragraphe. - [6] Cours PHP / MySQL, partie 1, chapitre 9 QCM, question 1

Messieurs les organisateurs, messieurs les candidats, POUR LA SCIENCE .

P.S. : L'auteur de se papier présente des trouble psychopathologiques graves, merci de ne pas vous attarder sur la validité de cette étude.

dim, 29/01/2012 - 22:57 — katagoto

> Tu arrive à écrire des mots de plus de trois syllabes, bravo !
J'ai l'impression d'être pris pour un bon à rien.
Parfois j'essaye cinq, mais je ne me souviens
Si c'est bien avant ou après quatre. Mais bon,
Trois syllabes, il faut déjà faire attention.

epsilon012 : je pensais que ton rendu en brainfuck le démontrait assez bien, mais tu es vraiment un grand malade.

J'en compte 13 pour la première. Mais je compte mal.

"la complexité caché"
s/caché/cachée !

Sinon, katagoto, c'est bien de dire d'argumenter, mais si tu le faisais toi-même, ce serait mieux ...

lun, 30/01/2012 - 13:48 — katagoto

> idem, l'analogie n'est pas un argument.
a dicto simpliciter ad dictum secundum quid
Une phrase n'est pas un argument.
Tu n'utilises que des phrases.
Donc tu ne donnes pas d'argument.
J'ai connu moins fallacieux.

lun, 30/01/2012 - 23:54 — katagoto

> epsilon012 m'a gentillement fait comprendre que ça n'avait aucune importance
Plus sérieusement, j'ai mal pris ta réaction comme quoi je ne disais rien, je le disais peut être mal, mais tu as répondu de manière arrogante et sèche. Voilà ton message :

dim, 29/01/2012 - 16:57 — katagoto

> epsilon012 : je ne vois pas l'intéret de ton message [si tu pouvais apporter
> des faits, des arguments et des démonstrations, juste pour avancer].
(Je crois que la seconde partie a été ajouté après un edit.) Que puis je répondre à cela ? Rien de sérieux en tout cas. J'ai donc tenté de répondre en instaurant un climat complètement absurde dans mon message. Encore une fois, il n'y avait pas grand chose à répondre à cette réponse (qui était plutôt maladroite de ma part), mais tu as choisi certainement la pire des solutions :

dim, 29/01/2012 - 22:57 — katagoto

> Tu arrive à écrire des mots de plus de trois syllabes, bravo !
Sur ce forum, on essaye de ne pas insulter directement quelqu'un. Ça arrive qu'on s'attaque en quelque sorte « indirectement », mais au fond on se ressemble un peu tous (c'est un des buts du concours rassembler des gens partageant la même passion.)

In the end, je m'excuse si j'ai été un peu agressif, mais je vais répéter une troisième fois (dans ce troisième message) mon sentiment sur les langages de programmation en général :
Il y a bien une chose que je n'aime pas, c'est le développement sauvage d'un langage, c'est pour cela que j'apprécie le C++ (et le WG21, même si repartir à zéro, de type D, ça serait pas mal aussi) et le Perl (on sera tous mort avant la sortie de Perl 6) mais que je n'aime pas des langages comme PHP et Java.

lun, 30/01/2012 - 12:37 — Ekleog

> "la complexité caché"
> s/caché/cachée !
Mais, mais, il y avait beaucoup à relire professeur ! :(
Le nombre de J'J'eurs automatiques est en pleine explosion…

> Si tu va par là vu que la plupart des langages sont turing complet, donc la plupart des langages n'apportent rien.

Pardon ?

katagoto :
"Mais !?
[...]
Compile-time != exécution"

Duck typing est ce qui permet de ne pas se préoccuper du type réel d'un objet.
Donc PHP le permet à l'exécution, et C++ à la compilation.
PHP lance une exception à l'exécution si la fonction appelée n'existe pas, C++ à la compilation.

Où est donc la différence ?

"Je pense qu'ils ne cherchent plus à faire quelque chose de cohérent."
En effet, avec ce qui a été fait ...
Le majeur reproche contre PHP étant son incohérence, tu es donc d'accord avec nous ?

"Oui, mais tout dépends de ce que tu appel "choses compliquées""
(au passage, désolé de la typo)
Prologin, pour moi, est le début des choses compliquées.

xarch : +1

Étant donné que le dernier message argumenté est le mien (si on considère que l'alien n'en est pas un, ce qui reste à prouver : le premier message de notre aliéné préféré était argumenté, contrairement à ce que tu peux dire), je pense être en droit de te demander d'argumenter, et non l'inverse.
Le dialogue socratique correspond à deux parties qui parlent l'une après l'autre. (enfin, bon, normalement il y a toujours un Glaucon ou autre qui se contente de "oui", mais on va passer sur ce point)
Les derniers arguments étant des en ma faveur, et voyant que tu n'y réponds pas, j'en déduis que tu n'as pas de réponse et que la part "PHP, c'est possible à utiliser, mais c'est pourri, par les mauvais utilisateurs, pour les choses compliquées" a gagné.
Ou bien tu réponds aux arguments exposés dans mon message du "dim, 29/01/2012 - 01:20" et à celui d'epsilon du "dim, 29/01/2012 - 13:55" ?

"La différence c'est qu'en PHP les exceptions de ce genre sont d'une part "catchable" (j'ai un doute en C++) et d'autre part qu'on à la surcharge (ou méthodes magiques) pour empêcher ces erreurs."
Spécialisation de template.
Et une erreur de compil' n'est pas catchable, logique.
Mais c'est normal, puisque dans tous les cas c'est un code qui n'a aucun lieu d'être.

"Pour moi le duck typing ce n'est pas que de la syntaxe, c'est aussi de la sémantique."
Pour moi, le duck typing, c'est quand on lance des fonctions sur un objet sans trop savoir si il les a, et qu'on espère qu'il les a.
Si il ne les a pas, il y a eu un problème.

"La finale est quelque chose de compliquée, le reste est jouable, même si ce n'est pas élégant du tout."
En effet, le reste est jouable. Mais l'élégance n'est-elle pas le second point de recherche du développeur ? Juste après la paresse, entre autres celles d'avoir à apprendre des fonctions aux noms plus ou moins originaux ?

Il n'empêche que le PHP n'est pas fait pour l'algorithmique, et il semblerait que l'on se soit mis d'accord sur ce point.

"Pour moi, le duck typing, c'est quand on lance des fonctions sur un objet sans trop savoir si il les a, et qu'on espère qu'il les a."

Or le C++ requiert de pouvoir prouver statiquement qu'un objet a bien les méthodes qu'on appellera potentiellement (en particulier parce qu'il ne peut pas trouver une méthode à partir d'un nom à l'exécution). Le C++ n'a pas de duck typing, mais c'est un peu une question de vocabulaire : les templates permettent statiquement des choses similaires dans un certain nombre de cas. Le duck typing est dynamique.

Par exemple, une fonction renvoie parfois un objet de type Foo, parfois de type Bar. On appelle ensuite des méthodes sur l'objet renvoyée.
Par exemple, on met plein d'objets, de type différents, dans une liste ou table de hachage. Et ça n'empêche pas de les utiliser par la suite, à condition que les méthodes utilisées existent finalement.
Avec le duck typing, on veut parfois tester dynamiquement si la méthode existe pour choisir ce que l'on fait.

C++ est assez différent de tout ça. C# 4.0 a du duck typing optionnel (via le mot-clé "dynamic"), pas le C++.

"Le duck typing est dynamique."
Est-ce obligatoire ?

Au passage, il y a moyen d'avoir du duck typing dynamique en c++ : faire tout hériter et mettre une méthode virtual "call", surchargée avec des arguments jusqu'à N, et voilà.
Si on veut ajouter la vérification d'existence d'une méthode, on ajoute une méthode virtual has.
Si on veut accéder à une variable, on met une fonction à 0 arguments qui renvoie un pointeur vers la fonction.
etc.

mar, 31/01/2012 - 23:28 — Ekleog

>

mar, 31/01/2012 - 23:15 — katagoto

>> "La différence c'est qu'en PHP les exceptions de ce genre sont d'une part
>> "catchable" (j'ai un doute en C++) et d'autre part qu'on à la surcharge (ou
>> méthodes magiques) pour empêcher ces erreurs."
> Spécialisation de template.
> Et une erreur de compil' n'est pas catchable, logique.
> Mais c'est normal, puisque dans tous les cas c'est un code qui n'a aucun
> lieu d'être.
Certaines erreurs de compil sont catchables , ou du moins on peut les ignorer et passer à autre chose, c'est le principe même du SFINAE. On peut d'ailleurs utiliser ça pour décider la présence d'une fonction membre à la compilation.

@Ekleog :
Bon après, on peut toujours prier pour que N3340 passe… Je cite :

N3340 (Dean Michael Berris, Matt Austern, Lawrence Crowl)

> This paper proposes the definition of a standardized rich pointer and type
> descriptor construct in C++ to allow for standardized and efficient runtime
> introspection of types and objects.
Mais bon, c'est le plus WTF des paper pre-Kona.

mer, 01/02/2012 - 12:17 — katagoto

> Certes, mais là c'est de la surcharge, ou du duck typing simulé, ce n'est
> plus que de la syntaxe
En effet en faisant comme cela, on peut écrire un interpréteur de n'importe quel langage "raisonnable" dans un langage turing complet donc au fond il n'y a pas de débat.
C++ n'a pas de duck typing "built in" et ce n'est vraiment pas le genre de fonctionnalité souhaité pour l'instant. Par le papier que j'ai cité à Ekleog (N3340, une proposition d'ajout au standard C++) ce sera peut être supporté, mais je ne pense pas que ce sera utilisé en masse, ça ne colle pas avec le reste du langage. En plus, le papier en question est vraiment WTF (ça fait un peu "ajoutons le support des licornes en C++"), donc il ne sera sûrement pas accepté avant plusieurs (« dixaines d' » ?) années (s'il est accepté).

Je pense que le point premier d'Ekleog c'était surtout « en PHP on utilise des choses sans le savoir, e.g. duck typing ». Venant d'un codeur C++, c'est une chose assez importante puisque C++ permet très facilement de savoir ce qu'il ce passe. Par exemple, contrairement à un grand nombre de langage (oui, je te regarde Java), en C++, on sait exactement quand un objet sera détruit, ce qui permet de faire du SBRM ( Scope Bound Resource Management ). Cela permet de ne pas avoir à gérer les ressources, c'est cette technique qui est utilisé par les smart pointers pour la mémoire, mais qui est également utilisé par std::fstream (ainsi en C++, on a pas besoin d'appeler l'équivalent du fclose de C à chaque return/exception).
C'est pour cela, qu'on a du mal avec tous ces langages où on a l'impression que plein de (potentiellement mauvaises) choses ce passe sans que le programmeur le sache (voire même ne puisse le savoir).

"Certes, mais là c'est de la surcharge, ou du duck typing simulé, ce n'est plus que de la syntaxe, bref, si tu pouvais avoir une définition claire et stable, moi j'ai l'impression que tu l'adapte à chaque fois qu'on te contre-dit."
Ma définition n'a jamais changé : c'est pouvoir utiliser un objet sans se soucier de son type. C++ le permet à condition que le type soit connu à la compilation avec les templates, et à l'exécution avec l'héritage.
Au passage, comment crois-tu que PHP soit implémenté ? Certainement avec de l'héritage.

epsilon012 : Un énorme +1 (et +42 pour le dernier paragraphe)

C'est pour cela, qu'on a du mal avec tous ces langages où on a l'impression que plein de (potentiellement mauvaises) choses ce passe sans que le programmeur le sache (voire même ne puisse le savoir).

Ca s'appelle un langage de haut-niveau et des abstractions.
Un développeur C reprochera la même chose au C++ : entre les objets de la STL, la surcharge d'opérateurs, les constructeurs implicites, les destructeurs, etc. il se passe pas mal de choses aussi. C'est pas toujours simple de savoir, par exemple, ce qui est copié et quand (il suffit d'oublier un "&" et un programme pourra prendre 10 fois plus de ram, sans changer de comportement visible).

Après, oui, je suis d'accord, PHP est pourri. Si on préfère un langage dynamique, autant aller voir du côté de Ruby.

"Le duck typing est dynamique." - Est-ce obligatoire ?

Je dirais que oui, par définition (en existe-t-il vraiment une ?). Le comportement que tu décris, je l'appellerais plutôt "typage structurel". C'est aussi ce qu'on retrouve avec les objets en Ocaml. C'est chouette, en théorie. En pratique, les temps de compilation et les messages d'erreurs font que ce n'est pas toujours aussi bien qu'on le voudrait.

"les objets de la STL" - Eux sont transparents, non ? Enfin, pas dans leur fonctionnement, mais dans leurs actions.
"la surcharge d'opérateurs" - Que se passe-t-il dans mon dos quand je les utilise ? (c'est une vraie question)
"les constructeurs implicites" - D'où le explicit (bien qu'il aurait peut-être été meilleur de mettre explicit par défaut et de proposer implicit)
"les destructeurs" - A la fin de la vie d'un objet (delete, retrait de la stack, ...) le destructeur est appelé. Et tant mieux, sinon il y a perte de mémoire. Où est la chose cachée ?
"C'est pas toujours simple de savoir, par exemple, ce qui est copié et quand" - Là, +1, d'où l'avantage d'avoir un analyseur statique de code qui fait un warning à la copie d'un objet de plus de N octets - ou bien tout simplement de faire attention !
Bon, j'admets, certains arguments ici ne sont pas très recevables. Mais il faut avouer que les destructeurs, par exemple, apportent plus que ce qu'ils ne gênent.
Pour moi, les deux seules choses qui font vraiment des choses dans le dos, ce sont les exceptions et . Parce qu'ils génèrent beaucoup de code inutile une bonne partie du temps.

"Je dirais que oui, par définition (en existe-t-il vraiment une ?). Le comportement que tu décris, je l'appellerais plutôt "typage structurel"."
Bon, c'est une question de vocabulaire, alors.
Pour moi c'était une forme (light) de duck typing, après comme il n'y a pas de définition, chacun met ce qu'il veut dessus.

"C'est chouette, en théorie. En pratique, les temps de compilation et les messages d'erreurs font que ce n'est pas toujours aussi bien qu'on le voudrait."
D'où les concepts, qui permettraient de simplifier les messages d'erreur en annonçant clairement ce qu'on veut. J'espère que ce sera bon pour la prochaine norme c++.
Et, pour les temps de compilation, c'est en partie possible à résoudre par les templates exportées, ou (plus portable) par les instanciations explicites. Exemple : J'ai une paire de fichiers a.hpp et a.cpp ; je sais que a.cpp utilise MaTemplate . Je vais créer une instanciation explicite dans a_inst.cpp ; l'annoncer dans a.hpp ; et je n'aurai plus à compiler MaTemplate à chaque modification de a.cpp. C'est magique, non ? =D

Ca va pas de parler autant ? On peut plus répondre ! :(

sam, 28/01/2012 - 12:49 — Ekleog : « car on doit utiliser telle ou telle librairie »
→ Trois chatons viennent de mourir. D'un coup.

Sinon pour moi le duck typing, il se voit surtout au niveau des types primitifs (enfin, du moins c'est plus facile de le voir ici). Par exemple l'opérateur ==, ou ça :

1
2
3
4
5

$a = "42";
$a++;
var_dump($a);
?>
Sortie : int(43)

sam, 28/01/2012 - 13:44 — katagoto :
« Pour l'instant c'est un tableau, si tu fais \$tbl[42] = 42; là ça devient une table de hachage.
Comme en C, ou bien on utilise array_push, array_pop, etc. Nous avons également une palette d'interface qui gère ça très bien.
Tout ça pour dire qu'on peut avoir le contrôle de ses types en PHP. »

→ Pour implémenter un système de BBCode, j'ai utilisé les arrays de PHP pour faire des piles et des arbres. Les piles, ça passe bien, mais mon dieu quelle galère de se dépatouiller avec les "références" du PHP pour parcourir et modifier un arbre ! En plus de ça, la syntaxe sera automatiquement moche (enfin, tu peux encapsuler dans une classe, soit) et comme derrière t'as des ordered maps tu perds le côté performances de ta structure.

A part ça, epsilon, j'ai explosé de rire devant ta "démonstration". :D Merci !

"Trois chatons viennent de mourir. D'un coup."
Les pauvres !
Sinon, abus de langage. En fait, j'ai tellement l'habitude de parler en anglais que ça vient naturellement, et j'arrive à peine à me contrôler pour mettre un "ie". (Bon, d'accord, je raconte n'importe quoi. Mais bon, j'espère que leur maman va me pardonner !)

Leur maman s'est suicidée juste après.