Réflexions sur la documentation

Bonjour Wam,

que veux-tu dire par :

elle n'apparaît pas dans la déclaration de l'espèce, et donc dans le listing de toutes les méthodes qu'elle propose.

Nous avons établis que, pour qu'une méthode fonctionnelle se révèle utile, elle doit :
- être inscrite dans la déclaration de l'espèce pour indiquer qu'elle appartient à l'objet, ce qui rend sa modification très facile.
- être facilement identifiables au milieu du code.

Or, en créant une méthode fonctionnelle dynamiquement, elle n'apparaîtra pas ici :

admincpc a écrit:

[php]
espèces
énergie :: nombre <
- 1000
nom :: texte
espèce stormtrooper contient énergie
espèce stormtrooper sait attaquer, perdre énergie, diagnostiquer
espèce jedi contient énergie, nom
espèce jedi sait frapper, prendre coup, respire encore, diagnostiquer

[/php]

Du coup, notre espèce perd en lisibilité car stromtrooper pourrait par exemple disposer d'une méthode fonctionnelle "contre-attaquer".

La déclaration d'une espèce, proposant le listing de tous ses attributs et méthodes, serait alors faussé.

J'ai envie de dire que ça ne me choque pas !

Si le programmeur a ajouté la méthode "contre-attaquer" à un prototype et un seul, ça été son choix.

S'il veut que la déclaration de la fonction "contre-attaquer" soit effective pour tous les prototypes, alors, il la déclare dans la section espèces"

A part "propose" ou "sait", d'autres idées ?

Et voici les copies d'écran pour Fedora et Ubuntu !

Je constate que dans la bêta 2.1, la ligne "Livre" du sommaire à été supprimée, affichant seulement le nom des fonctions.

Pourrait-on ajouter les sections Espèces et Globale dans le sommaire ?

Cela faciliterais encore la navigation dans le livre.

Terminé le temps où je pouvais supprimer ou modifier l'Atelier discrètement " title="Smile" />

L'idée est bonne, je vais y réfléchir.

Maintenant avant chaque modification tu dois demander un accord signé par écrit à Wam x)

Un popup étant un élément d'IHM, je pensais qu'on devait le déclarer dans la section Globale.

Or, j'ai constaté que pour utiliser un popup, on pouvait le déclarer directement dans une fonction :

[php]
Globale
fenêtre est un formulaire, hauteur vaut 200, largeur vaut 400, titre vaut "Ma première fenêtre"
b1 est un bouton, visible vaut "oui", x vaut 100, y vaut 100, texte vaut "Push !"

Principal :
début
Ajoute b1 dans fenêtre
Fais réagir fenêtre à "clic souris" pour Quitter

// Boucle infinie
Tant que vrai, temporise

Quitter :
popup1 est un popup
début
évoque popup1.message("A bientôt !")
Termine
[/php]

Du coup, qu'elle est la meilleure option :
- déclarer le popup dans la section Globale ?
- déclarer le popup dans la fonction ?

Étant donné que les éléments des IHMs ne font pas partis d'aucun algorithme, j'ai pris l'habitude de les déclarer dans la section globale.
De plus, ça optimise le code car ça évite de les instancier à chaque fois que l'on entre dans une fonction.

zamirh a écrit:

Maintenant avant chaque modification tu dois demander un accord signé par écrit à Wam x)

" title="Big Grin" />

Dans ce cas, il faudrait peut-être forcer la déclaration des éléments d'IHM dans la section Globale du livre ?
Sa éviterais à l'utilisateur de pouvoir les déclarer dans n'importe quelle fonction et sa optimiserais ainsi son code.

460 téléchargements pour la version 2.0.4 de ton tutoriel.
Pas mal !

:O Tant que ça ?

C'est sûr, ça fait plaisir x)

Je constate que l'espèce liste contient beaucoup de méthodes fonctionnelles, dont ne dispose pas l'espèce sélecteur.
En effet, le sélecteur ne dispose pas d'une méthode .ajoutervaleur()
Ni d'une méthode .valeurs()
Il ne dispose pas non plus d'infobulle.

Pourquoi cette discrimination ?

Il est vrai que je devrais ajouter ces méthodes fonctionnelles.
C'est noté pour la prochaine version :
https://code.google.com/p/langagelinott ... ail?id=125

Voici les retours sur ton nouveau tuto :

Bravo pour le travail, c'est un gros document maintenant !

voici ce que j'ai noté :

page 60 : "ça donne"
page 69 : -->
ça me rappelle que je dois modifier l'atelier afin qu'il n'écrive plus "::" mais "est un"
page 72 : "ça va très vite"
page 110 : -->
on n'est plus obligé d'écrire *moi :: majordome. Il est ajouté implicitement.

admincpc a écrit:

page 110 : -->
on n'est plus obligé d'écrire *moi :: majordome. Il est ajouté implicitement.

Mais si on prend mon exemple en entier :

[php]
Espèces
prénom est un texte valant "Albert"
espèce majordome contient prénom
majordome propose présentation

Présentation de majordome :
*moi est un majordome
phrase est un texte
début
phrase vaut "Bonsoir, mon cher, je suis votre serviteur " + prénom de moi
Retourne phrase

Démonstration :
messager est un majordome
début
Affiche messager.présentation()
[/php]

Dans cet exemple, je suis bien obligé d'utiliser le paramètre *moi pour pouvoir utiliser l'attribut prénom.

Ainsi, afin de garder une une certaine logique lors de l'écriture de cet exemple, j’inscris déjà le paramètre *moi dans mon exemple précédent, en justifiant qu'une méthode fonctionnelle prendra "généralement" un paramètre.

Dans la suite de mon chapitre, j'explique bien que la présence du paramètre n'est pas nécessaire, si on n'utilise pas d'attribut de l'espèce dans notre méthode fonctionnelle (p.114)

J'ai quand même effectué 2 modifications :

- Cette fonction étant une méthode fonctionnelle, il convient de respecter "2 ou 3" règles (p.109)

- On remarque que la méthode fonctionnelle Service ne dispose pas de paramètre.
En effet, comme on n'utilise aucun attribut de l'espèce majordome dans notre méthode fonctionnelle, et que, lors de son appel, on ne transmet aucune variable (ligne 23), alors il est inutile d'y ajouter un paramètre. (p.114)

En espérant que ça soit plus clair ^^"

Pourtant, j'ai supprimé le paramètre moi :

[php]
Espèces
prénom est un texte valant "Albert"
espèce majordome contient prénom
majordome propose présentation

Présentation de majordome :
phrase est un texte
début
phrase vaut "Bonsoir, mon cher, je suis votre serviteur " + prénom de moi
Retourne phrase

Démonstration :
messager est un majordome
début
Affiche messager.présentation()

[/php]

et ça fonctionne

Étant donné que présentation est attaché syntaxiquement à majordome, il me paraissait logique que je propose directement l'acteur "moi". ça simplifie la syntaxe ?

Ah, je ne savais pas que la variable "moi" existait... ^^

Du coup, il va falloir que je modifie tout mon chapitre, huhu ^^"

Reste à savoir la façon la plus simple ! En tout cas, les deux existent !

Du coup, comment je peux nommer la variable moi ?
C'est une variable anonyme ?
Une variable particulière ?
C'est le joker des méthodes fonctionnelles ?
...

Je n'ai pas encore qualifié cette variable.
Ce n'est pas une variable particulière sinon, il serait impossible de la créer.
De plus, elle n'existe que lors que l'on se trouve dans une méthode fonctionnelle d'une espèce.

Il faudrait lui trouver un nom, que je puisse la mettre dans le tuto :p

Je n'ai pas trop d'idée pour l'instant.
Mais on toujours considérer cet acteur "moi" comme un acteur particulier.

Du coup, en attendant, je l'ai appelé paramètre particulier ^^

Du coup, ne pourrait-on pas utiliser le paramètre particulier "moi" pour les événements ?

[php]
Décor :
soleil est un cercle, x vaut 311, y vaut 285, couleur vaut "jaune", plein vaut "oui", rayon vaut 50
début
Projette soleil
Fais réagir soleil à "clic souris" pour Changer la couleur

// boucle infinie
Tant que vrai, lis
Temporise
Ferme

Changer la couleur :
début
couleur de moi vaut "rouge"
Reviens
[/php]