Programmer avec le langage Linotte
Vous souhaitez réagir à ce message ? Créez un compte en quelques clics ou connectez-vous pour continuer.

Programmer avec le langage LinotteConnexion

Besoin d'un conseil sur la programmation en Linotte ?

-50%
Le deal à ne pas rater :
-50% Baskets Nike Dunk Low
64.99 € 129.99 €
Voir le deal

Réflexions sur la documentation

power_settings_newSe connecter pour répondre
+2
zamirh
pat
6 participants

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Je pourrai utiliser le signe =

si a = b , a = c

Mais du coup, certaines phrases seraient difficiles à comprendre

par exemple :
affiche a = b
a = a = c

En utilisant ==, c'est plus clair :
affiche a == b
a = a == c

Plus de confusion !

J'ai utilise le symbole == car il est utilisé dans la plupart des langages de programmation.

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Je n'avais jamais tenté d'utiliser le verbe afficher directement avec une condition ^^

J'ai d'autres questions concernant l'IHM :

La méthode fonctionnelle .transparence(nombre) fonctionne ?
Car dès que je change la valeur (qui est à 100 par défaut) voici le message d'erreur qui s'affiche :
La valeur est incorrecte : Erreur interne au greffon !

Concernant la méthode fonctionnelle .àpropos() : quel est le titre exact de la fenêtre (car elle n'est pas assez grande pour l'afficher) ?

Et enfin, lorsque l'on donne un titre à une fenêtre, celui-ci s'affiche trop haut dans la barre de titre, excepté pour le thème Java Métal.

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
- La méthode fonctionnelle .transparence(nombre) fonctionne ?
Normalement... Tu peux tester l'exemple Demonstration_IHM, dernier onglet FX.


- Concernant la méthode fonctionnelle .àpropos() : quel est le titre exact de la fenêtre (car elle n'est pas assez grande pour l'afficher) ?
- Et enfin, lorsque l'on donne un titre à une fenêtre, celui-ci s'affiche trop haut dans la barre de titre, excepté pour le thème Java Métal.

Tu n'as pas le même affichage ?

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Voici mon code :

[php]
Globale
fenêtre est un formulaire, hauteur vaut 500, largeur vaut 500, titre vaut "Ma première
fenêtre"
b est un bouton

Principal :
début
Ajoute b dans fenêtre
évoque fenêtre.àpropos()

Tant que vrai, temporise
[/php]

Et voici le résultat :

- Concernant la méthode fonctionnelle .àpropos() : quel est le titre exact de la fenêtre (car elle n'est pas assez grande pour l'afficher) :

[attachment=108]

- Et enfin, lorsque l'on donne un titre à une fenêtre, celui-ci s'affiche trop haut dans la barre de titre, excepté pour le thème Java Métal :

[attachment=109]

- La méthode fonctionnelle .transparence(nombre) fonctionne ?
Normalement... Tu peux tester l'exemple Demonstration_IHM, dernier onglet FX.

L'exemple plante et j'ai le message d'erreur suivant :

La valeur est incorrecte : Erreur interne au greffon !

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
ça fonctionne bien...

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Bah pas chez moi ^^"

Peut-être à cause de l'OS (j'utilise Windows XP) ?

Peut-être à cause du thème ?
Le titre de la fenêtre est correctement affiché avec le thème Metal.
En revanche, même le thème Metal n'affiche pas le titre de le fenêtre "A propos" en entier...

En ce moment même, plus j'exécute ce programme et plus le titre de ma fenêtre se décale vers le haut, comme ceci :

[attachment=111]


De plus, si j'utilise cette instruction dans mon livre :

[php]
Explore "coloriser javax.swing.plaf.metal.MetalLookAndFeel"
[/php]

Cela provoque des comportements étranges :
- plantage de l'atelier (je ne peux plus cliquer sur le bouton Aide et tout se fige au fur et à mesure)
- ou alors réduction de l'atelier

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Je n'ai pas ce problème et pourtant, j'ai deux pc avec Windows xp sp3 !
étrange...

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Le problème du titre de la fenêtre est corrigé !
Je copiais/collais mon code depuis le bloc note.
Si j'écris mon code à la main dans le cahier, pas de problème, le titre de la fenêtre est bien positionné.

Pour ce qui est du titre de la fenêtre àpropos qui ne s'affiche pas en entier, cela doit être un problème de taille de police, non ?

Reste le problème de changement de thème par le verbe Explorer qui fait planter l'atelier...

Edit :

Je confirme pour la taille de la police :
J'ai modifié la taille de la police dans les paramètres d'affichage de Windows et le titre de la fenêtre àpropos s'affiche désormais en entier x)

Pour le verbe Explorer, j'ai le même problème avec l'exemple décorateur.liv : le changement de thème fait planter l'atelier.

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Concernant l'architecture MVC, peut-on la résumer comme ceci :

[php]
/*Spécification : 0.7.2*/
globale
x :: nombre <
- 40
y :: nombre <
- 40
form :: formulaire, titre vaut "Le peintre", largeur vaut 300, hauteur vaut 260
b1 :: bouton, texte vaut "Rouge", x vaut x, y vaut y
b2 :: bouton, texte vaut "Vert", x vaut x, y vaut y + 40
b3 :: bouton, texte vaut "Orange", x vaut x, y vaut y + 80
b4 :: bouton, texte vaut "ok", x vaut x + 180, y vaut y + 120 // Modèle
l1 :: étiquette, texte vaut "Choisissez la couleur :", x vaut x, y vaut y - 30
l2 :: étiquette, texte vaut "", x vaut x, y vaut y + 170
c1 :: champ, x vaut x, y vaut y + 120
toile :: toile, couleur vaut "blanc"

formulaire :
début
Projette toile
Ajoute b1 & b2 & b3 & l1 & l2 & c1 & b4 dans form // Vue


Fais réagir b1 & b2 & b3 à "clic souris" pour changer la couleur
Fais réagir b4 à "clic souris" pour récupère la couleur // Contrôleur
Fais réagir form à "clic souris" pour fermer la fenêtre

Tant que vrai, lis
temporise
Ferme

changer la couleur :
*b :: bouton
début
Affiche texte @ b
Couleur @ toile vaut texte @ b
Texte @ l2 vaut "Couleur affichée :" + texte @ b
Titre @ form vaut "Le peintre vient de peindre en " + texte @ b
Reviens

récupère la couleur :
*b :: bouton
début
[/php]

Le modèle correspond alors aux éléments d'IHM déclarés dans la section Globale.
La vue correspond à la construction des fenêtres dans la fonction formulaire.
Le contrôleur correspond à la gestion des événements.

Est-ce exact ?

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Oui et non... c'est un gros résumé !

Un des principes du MCV est de bien séparé la partie modèle et vue.

Mais dans ton exemple MV sont ensembles.

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Voici ce que tu m'avais dit auparavant :

Il est mieux d'initialiser tous les évènements au début d'un programme... c'est la meilleur des méthodes car elle est plus clair au niveau de ton programme car tu construis ton application graphique au début de ton programme et aussi au niveau des performances, c'est fait une seule fois !

Ce modèle de programmation est le modèle MVC (Modèle-Vue-Contrôleur):
Dans le modèle MVC, la gestion des évènements est le contrôleur : http://fr.wikipedia.org/wiki/Mod%C3%A8le....C3.B4leur

Tes fenêtres sont "la vue".


Dans ce cas, en Linotte, ou intervient le modèle ?

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Ce modèle est simplifié en Linotte.

Le modèle est représenté par les acteurs de tes objets graphiques (la vue).

L'idéal aurait d'avoir eu des objets graphiques et des objets modèles.

Imaginons :

[php]
boutonmodèle est un texte valant "rouge"
b1 :: bouton représentant boutonmodèle, x vaut x, y vaut y
[/php]

Dans cet exemple, le bouton s'appuiera sur boutonmodèle pour son affichage.

Mais ce n'est pas très simple pour un langage qui se veut ... simple !

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Donc, peut-on dire que l'espèce graphique bouton correspond à la vue, et ses attributs correspondent au modèle ?

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Pas simple de répondre à ta question !

En fait, du point de vue de programmeur du langage Linotte. Oui, c'est du MVC :

- les attributs des espèces sont les éléments du modèle
- le contrôleur qui gère les évènements est indépendant des espèces.
- la vue est gérée par un module particulier du langage et est au niveau des espèces graphiques.

donc, la phrase suivante a un sens :
"on dire que l'espèce graphique bouton correspond à la vue, et ses attributs correspondent au modèle"

Par contre, je ne pense pas qu'il faille aborder le sujet dans ton tuto, ça va compliquer la compréhension <img src=" title="Tongue" />

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Si de ton point de vue, l'architecture MVC est respectée, pour un utilisateur du langage, le modèle et la vue sont "mélangés".

Ne programmant pas le Modèle et la Vue séparément, peut-on alors parler d'architecture MVC ?

Dans le but de simplifier le langage, cette façon de programmer ne s'appliquant pas vraiment en Linotte, je n'en parlerais donc pas dans mon tuto.

Je souhaitais juste comprendre un peu mieux le fonctionnement de l'architecture MVC, qui se révèle très complexe, et son application au sein du langage Linotte, qui se veut simplifiée.

Merci pour ces éclaircissements :;
):

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Je continue mon étude sur les différents paradigmes de programmation.
Voici ce que j'ai compris, en ultra-schématisé :

Programmation impérative :

Permet :

l'assignation
les conditions
l'instruction va vers
les boucles
les variables globales


Programmation fonctionnelle :

Ne permet pas l'utilisation des variables globales mais peut permettre l'utilisation de variables locales.
La programmation fonctionnelle rejette également les notions de pointeurs et références.


Elle apporte :

les paramètres
la récursivité


La programmation fonctionnelle diminue ainsi les risques d'erreurs, induits par l'utilisation de variables globales, et facilite la modification du programme.

Un exemple concernant le langage Linotte :

Avant la version 2.0, on pouvait faire ceci :

[php]
Exemple1 :
Rôles :
nombre1 est un nombre
Actions :
nombre1 vaut 6
Va vers Exemple2

Exemple2 :
Rôles :
nombre1 est un nombre
Actions :
Affiche nombre1
[/php]

Dans Exemple2, nombre1 était alors égal à 6. Ceci correspond à de la programmation impérative.

Or, maintenant, lorsque l'on quitte une fonction, la valeur de la variable est réinitialisée.

Pour pouvoir faire la même chose, on utilise alors le verbe parcourir :

[php]
Exemple1 :
nombre1 est un nombre
début
nombre1 vaut 6
Parcours Exemple2

Exemple2 :
début
Affiche nombre1
Reviens
[/php]

Ceci correspond à de la programmation fonctionnelle. Elle a pour but d'empêcher une utilisation excessive de la variable nombre1 et donc de diminuer les risques d'erreur de programmation.



Programmation Orientée Objet :

En programmation orientée objet, le programme est considéré comme une collection d’objets en interaction.
L’une des particularités de cette approche est qu’elle associe les variables et les fonctions au sein d’un unique objet.


Elle apporte :

les espèces et attributs
les méthodes fonctionnelles
l'héritage

La programmation fonctionnelle utilisant un emboîtement de fonctions que l'on peut imbriquer les unes dans les autres, une modification du programme implique souvent une remise en question de l'ensemble des fonctions et sous-fonctions impliquées.
Une modification des données entraîne donc une modification d’un nombre important de fonctions éparpillées et difficiles à identifier.
En Programmation Orientée Objet, lors d'une modification des données, seul l’objet incriminé (encapsulant les données) est modifié.
Toutes les fonctions à modifier sont alors bien identifiées car elles se trouvent dans ce même objet : ce sont ses méthodes.


Est-ce que mon schéma est exact ?

Y aurait-il d'autres différences essentielles à ajouter ?

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Bonne analyse mais...

[php]
Exemple1 :
nombre1 est un nombre
début
nombre1 vaut 6
Parcours Exemple2

Exemple2 :
début
Affiche nombre1
Reviens
[/php]

Ce code fonctionne mais la question est posée si je vais garder ce fonctionnement en 2.0.4

Car il est plus "propre" d'écrire :
[php]
Exemple1 :
nombre1 est un nombre
début
nombre1 vaut 6
Parcours Exemple2 avec nombre1

Exemple2 :
*nombre1 est un nombre
début
Affiche nombre1
Reviens
[/php]

Dans le deuxième exemple, en lisant la fonction Exemple2, on peut comprendre facilement d'où peut venir la valeur de nombre1. C'est une entrée de ta fonction.

Dans le premier exemple, nombre1 peut venir soit d'une variable globale, soit de la méthode appelante ! Donc, potentiellement, gros risque de confusion et d'erreur !

Autre remarque quand tu dis "Or, maintenant, lorsque l'on quitte une fonction, la valeur de la variable est réinitialisée."

Non, la variable n'es pas réinitialisée car c'est tout simplement une autre variable dans une autre méthode !
La première variable a été détruite car nous sommes passé dans une autre fonction avec le verbe Aller.

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
- La méthode fonctionnelle .transparence(nombre) fonctionne ?

ça marche en java 1.6 mais plus en 1.7 !

Et c'est normal ! Ce que proposait java en 1.6 était temporaire et en attendant de proposer une solution plus viable.

Il faut que je trouve une solution qui fonctionne sur les deux versions de Java...

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Si j'ai bien compris l'utilité de la POO, à savoir :

Wam a écrit:


La programmation fonctionnelle utilisant un emboîtement de fonctions que l'on peut imbriquer les unes dans les autres, une modification du programme implique souvent une remise en question de l'ensemble des fonctions et sous-fonctions impliquées.
Une modification des données entraîne donc une modification d’un nombre important de fonctions éparpillées et difficiles à identifier.
En Programmation Orientée Objet, lors d'une modification des données, seul l’objet incriminé (encapsulant les données) est modifié.
Toutes les fonctions à modifier sont alors bien identifiées car elles se trouvent dans ce même objet : ce sont ses méthodes.



Pourtant, en Linotte, les méthodes ne sont pas clairement identifiées, pour deux raisons :

La première concerne le déclaration des espèces.

En effet, lorsque l'on déclare une espèce, comme ceci :

[php]
Espèces
nom est un texte
numéro est un texte
adresse est un texte valant "adresse inconnue"
espèce contact contient nom, numéro, adresse
[/php]

On ne voit que ses attributs.
On ne voit pas les méthodes de l'espèce.

Car, pour créer une méthode fonctionnelle, on doit "l'attacher" à notre espèce et ceci peut être fait dans n'importe quelle partie de notre code.

La solution pour le Linottien consiste alors à "attacher" toutes ses méthodes fonctionnelles au sein d'une même fonction.

Mais ne pourrait-on pas déclarer les méthodes fonctionnelles directement lors de la déclaration d'une espèce ?

En C++ par exemple, les méthodes fonctionnelles sont visibles dans le header, grâce aux prototypes.


La seconde raison concerne l'écriture des méthodes fonctionnelles.

En effet, en Linotte, on écrit une méthode fonctionnelle comme n'importe quelle fonction récursive : rien ne les différencie.

En c++, on précéde le nom de la méthode par le nom de la classe, suivit de deux points, comme ceci :

[php]
void Personnage::recevoirDegats(int nbDegats)
{

}
[/php]

Ainsi, à la lecture de notre code, on sait tout de suite que la fonction RecevoirDegats est une méthode de la classe Personnage.

Mais en Linotte :

[php]
attaquer :
*moi :: stormtrooper
force :: nombre <
- 100
début
mélange force
énergie@moi vaut énergie@moi - force * 10
retourne force

[/php]

Ceci est une fonction récursive ou une méthode fonctionnelle appartenant à l'espèce stormtrooper ?

Réponse :

[php]
principale :
armée :: casier de stormtrooper
début
si vivant(armée{i}), lis
dégât :: nombre
affiche ">
>
Attaque du stormtrooper n° " + i + " :"
dégât vaut attaquer(armée{i})

[/php]

C'est une fonction récursive.


En modifiant ces deux points, les méthodes fonctionnelles seraient ainsi plus visibles et l'intérêt de la POO face aux fonctions récursives serait alors plus explicite...
Car ainsi les méthodes fonctionnelles d'une espèce seraient clairement identifiées et toutes modifications de cette espèce serait donc facilitées.

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Oui, tu as raison.

C'est un problème sur lequel j'ai travaillé mais sans trouver de syntaxe claire.

La première étape était d'ajouter la notion de prototype au langage (http://langagelinotte.free.fr/forum/sho ... 78#pid5378

La deuxième étape était d'ajouter la notion de classe. mais sans succès.

Tes propositions rejoignent ce que je pensais mettre en place mais je trouve cette syntaxe compliquée pour ce langage.

[php]
prototype
nom :: texte
prénom :: texte
type contact contient nom, prénom

courriel@contact :
début
retourne nom@moi + "." + prénom@moi + "@masociete.fr"

principale :
client :: contact, nom vaut "Bidochon", prénom vaut "Robert"
début
affiche client.courriel()

[/php]

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Mon idée serait celle-ci :

Code:


Espèces
nom :
:
texte
prénom :
:
texte
courriel :
:
prototype
espèce contact contient nom, prénom, courriel

/* Ainsi, on peut voir directement toutes les méthodes fonctionnelles attachées à l'espèce */


principale :

client :
:
contact, nom vaut "Bidochon", prénom vaut "Robert"
début
affiche courriel() de client // La présence des parenthèses indique que courriel() est une méthode fonctionnelle et non pas un attribut

/* on conserve une similitude entre l'appel à la méthode fonctionnelle et sa création */

courriel de contact :
// méthode + de + espèce (idem à son appel)
début
retourne nom@moi + ".
" + prénom@moi + "@masociete.
fr"



Et bien sûr, on conserve l'idée de pouvoir attacher dynamiquement des méthodes fonctionnelles à une espèce :

[php]
Espèces
nom :: texte
prénom :: texte
espèce contact contient nom, prénom

principale :
client :: contact, nom vaut "Bidochon", prénom vaut "Robert"
début
attache courriel() à client
/* Là encore on utilise les parenthèses pour différencier les méthodes fonctionnelles des attributs
(ce qui n'est pas possible à l'heure actuelle) */

affiche courriel() de client

courriel de contact :
début
retourne nom@moi + "." + prénom@moi + "@masociete.fr"

[/php]

Qu'en pensez-vous ?

De cette façon, les méthodes fonctionnelles deviennent plus facilement repérables et mettent ainsi en évidence leurs intérêts :
- lorsque l'on modifie un objet (l'espèce contact), seul l'objet est incriminé : le listing de tous ses attributs ET méthodes fonctionnelles est alors indiqué en haut du livre, ce qui rend la modification très facile.
- on peut également modifier une méthode fonctionnelle sans avoir à modifier tout le code.

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Ton idée est bonne, à du sens et va dans la direction des recherches que j'ai déjà mené.
Mais je dois prendre en compte les spécificités du langage.

Voici que je propose :

[php]
prototype
nom :: texte
prénom :: texte
type contact contient nom, prénom et propose courriel, présentation

courriel de contact :
début
retourne nom@moi + "." + prénom@moi + "@masociete.fr"

présentation de contact :
* invité :: texte
début
retourne "Bonjour, " + invité + ", je suis " + prénom@moi

principale :
client :: contact, nom vaut "Bidochon", prénom vaut "Robert"
début
affiche client.courriel()
affiche client.présentation("Cpc")
[/php]

Mais je n'en suis pas très satisfait car on déclare deux fois que les méthodes fonctionnelles courriel et présentation sont attachées à l'espèce contact :

Code:


type contact contient nom, prénom et propose courriel, présentation

Code:


courriel de contact :

présentation de contact :



Le but est d'alléger au maximum le livre.

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Oui, mais c'est une condition obligatoire pour que les méthodes fonctionnelles soient utiles :
- elles doivent être inscrites dans la déclaration de l'espèce pour indiquer qu'elles appartiennent à l'objet.
- elles doivent être facilement identifiables au milieu du code.

C'est également le cas avec les attributs :

- ils sont inscrits dans la déclaration de l'espèce :

[php]
Espèces
nom :: texte
prénom :: texte
espèce contact contient nom, prénom
[/php]

- ils sont facilement identifiables au milieu du code :

[php]
retourne nom de Robert
[/php]

Les attributs sont juste plus précis lors de leur utilisation car ils indiquent à quelle variable de l'espèce ils appartiennent.
Ce qui n'est pas possible avec les méthodes fonctionnelles, car on devraient alors créer la même méthode pour chaque variable d'une espèce...

En revanche, on retrouve le même principe lors de la création dynamique d'une méthode :

[php]
attache courriel() à Robert // J'ai conservé les parenthèses pour différencier la méthode de l'attribut
[/php]

On indique ici à quelle variable appartient la méthode fonctionnelle.

Et :

[php]
courriel de contact :
début
retourne nom@moi
[/php]

On indique ici à quelle espèce appartient la méthode fonctionnelle.

Néanmoins, indiquer les méthodes fonctionnelles utilisables par l'objet dans la déclaration de l'espèce reste préférable à la déclaration dynamique.

De plus, si on prend l'exemple Starwar.liv, inscrire le nom de l'espèce comme ceci :

[php]
attaquer de stormtrooper :
*moi :: stormtrooper
force :: nombre <
- 100
début
mélange force
énergie@moi vaut énergie@moi - force * 10
retourne force
[/php]

Permettrait de pouvoir surcharger la méthode :

[php]
attaquer de jedi :
*moi :: jedi
*ennemi :: stormtrooper
force :: nombre <
- 500
début
mélange force
évoque ennemi.perdre énergie(force)
retourne force
[/php]

Chaque espèce bénéficieraient ainsi de la méthode attaquer() !

Idée farfelue :

Afin d'alléger le livre, les prototypes indiqués dans la déclaration d'une espèce pourraient être vu comme un commentaire par l'interprète :

[php]
Espèces
courriel :: prototype // le type prototype serait simplement ignoré par l'interprète
nom :: texte
prénom :: texte
espèce contact contient nom, prénom
[/php]

Le prototype ne servirait alors que d'indication pour l'utilisateur, en permettant le listing de toutes les méthodes fonctionnelles de l'espèce, sans avoir de réel impact sur l'interprète...

(Bien sûr, quand je dis "alléger le livre" je parle de la lecture du livre par l'interprète.
Si il s'agit d'alléger le livre pour le programmeur, ce n'est pas possible :
l'intérêt des méthodes fonctionnelles face aux fonctions récursives étant qu'elles soient plus facilement identifiables, cela passe forcément par l'utilisation d'une syntaxe spécifique...

Ainsi, en C++ par exemple, on utilise le header qui répertorie tous les prototypes dans la déclaration de la classe :

[php]
class Personnage
{
public:

void recevoirDegats(int nbDegats);


private:

int m_vie;

int m_mana;

};

[/php]

Et le fichier source, dans lequel le nom de la méthode est, là encore, précédé par le nom de la classe :

[php]
void Personnage::recevoirDegats(int nbDegats)
{

}
[/php]

Là aussi, on déclare donc deux fois que la méthode fonctionnelle est attachée à l'espèce.)

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Bonjour,

Même si je ne suis pas pressé d'implémenter cette façon de créer des espèces, je trouve l'idée intéressante d'y réfléchir.

Voici une autre proposition de syntaxe qui à l'avantage d'être très proche de la syntaxe actuelle du langage.

Version noir et blanc :

Code:


/*
Spécification 2.
1 :
Déclaration des prototypes syntaxiquement en Linotte
Auteur :
Wam / Cpc
*/
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

attaquer de stormtrooper :

force :
:
nombre <
- 100
début
mélange force
énergie@moi vaut énergie@moi - force * 10
retourne force

perdre énergie de stormtrooper :

*point :
:
nombre
début
énergie@moi vaut énergie@moi - point
retourne énergie@moi

diagnostiquer de stormtrooper :

début
si (énergie@moi) >
0, retourne vrai
sinon retourne faux

frapper de jedi :

*ennemi :
:
stormtrooper
force :
:
nombre <
- 500
début
mélange force
évoque ennemi.
perdre énergie(force)
retourne force

prendre coup de jedi :

*point :
:
nombre
début
énergie@moi vaut énergie@moi - point
retourne énergie@moi

diagnostiquer de jedi :

début
si (énergie@moi) >
0, retourne vrai
sinon retourne faux

principale :

prototype :
:
stormtrooper, énergie vaut 1000
yoda :
:
jedi, nom vaut "Yoda", énergie vaut 9000
armée :
:
casier de stormtrooper
taille armée :
:
nombre <
- 100
vivants :
:
nombre <
- taille armée
début
// On ajoute les clones du prototype dans l'armée :

pour chaque taille armée, ajoute #prototype dans armée
// ààà l'attaaaqueeee !
tant que vivants >
0, lis
i :
:
nombre
pour i de 0 à taille armée - 1, lis
si armée{i}.
diagnostiquer(), lis
dégât :
:
nombre
efface tableau
affiche ">
>
Attaque du stormtrooper n° " + i + " :
"
dégât vaut armée{i}.
attaquer()
affiche " Il vient de faire une attaque de " + dégât + " points.
"
affiche " Il reste " + yoda.
prendre coup(dégât) + " énergie à " + nom@yoda
si non(yoda.
diagnostiquer()), lis
affiche " " + nom@yoda + " est mort.
"
affiche "****L'alliance a perdu !"
termine
ferme
affiche "<
<
" + nom@yoda + " répond en attaquant.
.
.
"
dégât vaut yoda.
frapper(armée{i})
affiche " .
.
.
il vient de faire un attaque de " + dégât + " points.
"
affiche " Le stormtrooper a maintenant " + énergie@(armée{i}) + " points d'énergie.
"
si non(armée{i}.
diagnostiquer()), lis
affiche " Le stormtrooper n° + " + i + " est mort !"
décrémente vivants
ferme
attends 500 milliseconde
ferme
ferme
ferme
affiche " L'armée des clones est décimée !"
affiche "****L'alliance a gagné !"


Et version couleur :

[attachment=113]

descriptionRéflexions sur la documentation - Page 5 EmptyRE: Réflexions sur la documentation

more_horiz
Difficile de choisir entre cette syntaxe :

admincpc a écrit:

[php]
prototype
nom :: texte
prénom :: texte
type contact contient nom, prénom et propose courriel, présentation
[/php]



Et celle-ci :

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]


La seconde déclare deux fois une même espèce.
En revanche, comme elle sépare les attributs et les méthodes, c'est d'autant plus clair, surtout pour les espèces comprenant une longue liste.

En revanche, si on fait ceci :

[php]
Espèces
nom :: texte
prénom :: texte
espèce contact contient nom, prénom
espèce contact sait courriel // Pour le coup, le verbe "proposer" serait préférable
[/php]

Mais je me pose une question :
Est-ce bien raisonnable de pouvoir créer une méthode fonctionnelle dynamiquement ?
Car alors, 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.

descriptionRéflexions sur la documentation - Page 5 EmptyRe: Réflexions sur la documentation

more_horiz
privacy_tip Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum
power_settings_newSe connecter pour répondre