/* Topic des codeurs couche-tard [3] */

Sir Na Kraïou · Le 16/01/2011, à 03:10

cm-t · Le 16/01/2011, à 03:10

'Nuit;

Rolinh · Le 16/01/2011, à 03:15

Bonne nuit

Pylades · Le 16/01/2011, à 03:32

/me va rêver de la GPL…

nesthib · Le 16/01/2011, à 04:10

plop

Compteur du TdCCT · Le 16/01/2011, à 07:42

Scores totaux, depuis le début :

1) 2331    nesthib
2) 2207    samuncle
3) 1868    Pylade
4) 1518    Кຼزດ
5) 1126+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
6) 1068    cm-t
7) 787    helly
8) 783    \\Ouranos//
9) 776    Р☢w ! ✰ :mad: ✰ (эй !)
10) 603    gnuuat
11) 538    Lagierl
12) 366    tshirtman
13) 196    Askelon
14) 185    Kanor
15) 172    nathéo
16) 142    Rolinh
17) 138    The Uploader
18) 121    ǤƦƯƝƬ
19) 93    petifrancais
20) 78    edge_one
20) 78    pierguiard
22) 70    gulp
23) 63    kamui57
24) 37    ilagas
25) 35    Le Rouge
26) 30    keny
27) 25    GentooUser
27) 25    Morgiver
27) 25    xapantu
30) 24    ไ୦บเઢ'
30) 24    Steap
32) 20    CROWD
32) 20    d10g3n
34) 18    Ph3nix_
35) 15    timsy
35) 15    :!pakman
37) 14    kouskous
38) 12    stratoboy
38) 12    sailing
38) 12    sakul
41) 11    alexises
41) 11    Crocoii
43) 10    Toineo
43) 10    NutMotion
43) 10    pseudovingtcinqcaracteres
43) 10    pfriedZ
47) 8    Mornagest
48) 7    Vista
49) 6    Zeibux
49) 6    ubuntlin
49) 6    asma.geek
52) 5    tendances-tdct
52) 5    kinouchou
54) 4    danychou56
54) 4    Neros
54) 4    Biaise
54) 4    totoflute
54) 4    pinballyoda ㋛
59) 3    Revan26914
60) 2    SoJaS
60) 2    ceric
62) 1    geenux

Répartition Posts/heure

Compteur du TdCCT · Le 16/01/2011, à 07:42

Scores de la période en cours :

1) 142    samuncle
2) 130    nesthib
3) 103    Кຼزດ
4) 96    Pylade
5) 77    grim7reaper
6) 71    gnuuat
7) 61    Rolinh
8) 46    helly
9) 45    The Uploader
10) 44    Р☢w ! ✰ :mad: ✰ (эй !)
11) 20    Lagierl
11) 20    cm-t
13) 18    tshirtman
14) 15    \\Ouranos//
14) 15    :!pakman
16) 4    kamui57
17) 3    Steap
17) 3    xapantu
17) 3    Le Rouge

The Uploader · Le 16/01/2011, à 08:46

grim7reaper a écrit :

The Uploader a écrit :
PS : Le C ça fait un bien fou après l'Action Script.... X-)
Ouais, sauf que là c'est du C++, pas du C…

J'ai loupé quoi ? (j'ai évité la std, les boolens, les classes, passages par référence, etc...)

Dernière modification par The Uploader (Le 16/01/2011, à 09:03)

grim7reaper · Le 16/01/2011, à 09:46

Pylade a écrit :

Explicit is better than implicit.

Oui, c'est pour cette raison que l'on devrait empiler et dépiler explicitement les contextes nous-même à chaque appel de fonction

The Uploader a écrit :

grim7reaper a écrit :
The Uploader a écrit :
PS : Le C ça fait un bien fou après l'Action Script.... X-)
Ouais, sauf que là c'est du C++, pas du C…
J'ai loupé quoi ? (j'ai évité la std, les boolens, les classes, passages par référence, etc...)

Ça

int main()

(comme Rolinh l'a si bien remarqué)
et ça aussi.
M'enfin, c'est surtout le premier qui m'a fait tiquer.

Dernière modification par grim7reaper (Le 16/01/2011, à 09:47)

The Uploader · Le 16/01/2011, à 10:13

arf, ouais.. C'est corrigé ^^U

Pour le lien, le projet a change de langage, tout simplement.

grim7reaper · Le 16/01/2011, à 10:17

Ok, c'est bien ce que je pensais (c'est pour ça que je me suis surtout basé sur le prototype de main).
Vous faites ça en C89 ou en C99 (ça m'a tout l'air d'être orienté C99 pour le moment, mais je demande) ?

The Uploader · Le 16/01/2011, à 10:33

Ce que je vais intégrer (la gestion des collisions codé par un collègue) contiendra des bool, donc plutôt C99....

Quoique, j'ai remplacé tous mes bool par des int, mais je m'en fiche un peu si c'est pas strict C89, tant que ça reste du C.. (et puis le principal c'est que ça fonctionne).

edit : Il y a autre chose dans mon code qui soit du C99 à part les commentaires en fin de ligne ? ("//")
PS : ça se voit que ça fait trop longtemps que j'ai pas fait de "C pur", j'ai wikibooks ouvert à côté...

Dernière modification par The Uploader (Le 16/01/2011, à 10:36)

grim7reaper · Le 16/01/2011, à 10:43

The Uploader a écrit :

Ce que je vais intégrer (la gestion des collisions codé par un collègue) contiendra des bool, donc plutôt C99....
Quoique, j'ai remplacé tous mes bool par des int, mais je m'en fiche un peu si c'est pas strict C89, tant que ça reste du C.. (et puis le principal c'est que ça fonctionne).

Ok.
Bah disons que si tu fais du C99 autant y aller franc-jeu et bien profiter des nouveautés (un rapide aperçu ici)
Par exemple, c'est dommage d'utiliser des int au lieu des bool.

Perso je reste en C89 autant que possible (les apports du C99 ne me manquent guère, mis à part quelques-uns qui pourrait me servir à l'occasion). Le type bool se simulent très bien (enum ou #define, les commentaires // sont loin d'être indispensable, etc)
Bien que la norme aie plus de 10 ans, certains compilo on encore du mal avec (celui de Microsoft ne la supportait pas totalement la dernière fois que j'ai regardé, peut-être que ça a changé depuis…).

The Uploader a écrit :

edit : Il y a autre chose dans mon code qui soit du C99 à part les commentaires en fin de ligne ? ("//")

Oui, la déclaration de variables en milieu de bloc.

The Uploader a écrit :

PS : ça se voit que ça fait trop longtemps que j'ai pas fait de "C pur", j'ai wikibooks ouvert à côté...

Bah au pire, si tu as des questions on n'est pas mal de dev' C à fréquenter régulièrement ce topic

Dernière modification par grim7reaper (Le 16/01/2011, à 10:45)

gnuuat · Le 16/01/2011, à 10:47

ArkSeth a écrit :

gnuuat a écrit :
Alors pourquoi dans un langage sensé être plus accessible comme le python on le met en avant plan ?
Je ne suis pas le « Pyrfesseur thistman », mais je pense que c'est par construction : les méthodes sont d'abord liées à la classe, et donc il faut préciser à quel objet on les applique.

Oui, mais on n'a pas besoin de le faire de manière explicite, en C++ par exemple, on ne passe pas le pointeur this aux méthodes, c'est le compilateur qui fait tout le travail...

ArkSeth a écrit :

Ça permet par exemple, en cas d'héritage, à indiquer de façon explicite à quelle classe on fait appel pour exécuter une méthode donnée (notamment l'initialisation par ClasseMere.__init__(self)). Si on ne passait pas le pointeur, on ne pourrait pas appeler la méthode depuis le nom de la classe, et donc on aurait besoin d'un autre mécanisme pour remonter au parent.

J'ai peut être mal compris (un bout de code serait plus explicite), mais il me semble que tu continues sur la logique du premier paragraphe, à savoir le fait qu'on est obligé de passer le pointeur de manière explicite pour pouvoir bénéficier de l'accès aux attributs et aux méthodes de l'objet...
Ce qui n'est pas le cas : l'interpreteur pourrait s'occuper de faire le passage, et on aurait juste à utiliser self, sans avoir à le passer (comme PHP par exemple, qui utilise... this).

ArkSeth a écrit :

Et puis comme tu l'as dit, le choix de « self » est conventionnel, on peut très bien l'appeler autrement si on a envie, et ça, c'est fun (Même si on l'appelle tout le temps self quand même, le fait de pouvoir changer est amusant en soi)

Oui, mais si tu n'utilises pas self, les pythonneux ne pigeront plus rien à ton code ^^ .

Pylades · Le 16/01/2011, à 11:53

grim7reaper a écrit :

Pylade a écrit :
Explicit is better than implicit.
Oui, c'est pour cette raison que l'on devrait empiler et dépiler explicitement les contextes nous-même à chaque appel de fonction
[…]

Avoue que tu trolles, là…

grim7reaper · Le 16/01/2011, à 12:03

Non, je ne trolle pas -_-"

Plus le temps passe et plus on fait des langages de haut niveau (donc avec de l'abstraction). Le but étant d'aider le programmeur à se concentrer sur ce qu'il veut faire et non pas comment il doit le faire au niveau de la machine.
C'est bien pour ça que de plus en plus de choses sont implicite (placement des valeurs dans les registres, sauvegarde des contextes, allocation/libération de la mémoire, passage de this, etc).
Je ne trollais donc pas, je donnais juste un exemple pour montrer que je trouve ta citation absurde.

tshirtman · Le 16/01/2011, à 12:25

gnuuat a écrit :

Pyrfesseur thistman, pourriez vous, s'il vous plait, avoir l'amabilité de gentiment nous explique pourquoi, en Python, dans chaque méthode on doit passer en premier paramètre le pointeur sur l'objet (conventionnellement appelé self) ?
Je vois bien que c'est ce que fait en arrière plan le C++, mais c'est invisible pour le développeur...
Alors pourquoi dans un langage sensé être plus accessible comme le python on le met en avant plan ?

je viens de lire un peu, et c'est principalement le "explicit is better than implicit" oui, par ce qu'on tape dans un truc qui est dans le context, et il a pas pus y arriver magiquement, ça doit simplifier la conception du modèle objet du langage aussi.

Pylades · Le 16/01/2011, à 12:30

Voilà, c'est ce que je voulais mettre en avant avec cette citation.

Bon après, je n'ai pas d'avis personnel sur la question…

Dernière modification par Pylade (Le 16/01/2011, à 12:30)

grim7reaper · Le 16/01/2011, à 12:37

tshirtman a écrit :

je viens de lire un peu, et c'est principalement le "explicit is better than implicit" oui, par ce qu'on tape dans un truc qui est dans le context, et il a pas pus y arriver magiquement, ça doit simplifier la conception du modèle objet du langage aussi.

La mémoire non plus elle ne se libère pas magiquement, alors pourquoi c'est pas fais explicitement ?

Sinon, passer this (ou self) de manière explicite, c'est le genre de truc qu'on fait en C quand on essaye d'émuler de l'OO.
Java et C++ le font implicitement, même Perl 5 (qui à un modèle objet plus que déroutant, genre le truc qui donne l'impression d'être fait à l'arrache (même pas de public/private)) le fait implicitement…

Dernière modification par grim7reaper (Le 16/01/2011, à 12:45)

gnuuat · Le 16/01/2011, à 15:15

PHP aussi le fait, mais ce n'est pas parce que d'autres langages font les choses différemment que c'est mieux.
A mon avis, ce doit être moins difficile à comprendre pour un novice d'utiliser une variable qui a été passée en paramètre, plutôt qu'une variable sorti de nulle part...
Mais c'est discutable, car quand on fait appel aux méthodes, on ne leur p[asse pas ce premier paramètre (c'est fait par interpréteur)...

grim7reaper · Le 16/01/2011, à 15:19

C'est que je ne trouve pas logique, c'est un mélange d'implicite et d'explicite…

Elzen · Le 16/01/2011, à 15:42

gnuuat a écrit :

Oui, mais si tu n'utilises pas self, les pythonneux ne pigeront plus rien à ton code ^^ .

Si tu utilises this, les javaeux comprendront ^^
(Perso j'aime bien self, mais je maintiens que le fait que tu ne changes pas n'en retire pas moins l'aspect bien sympa de pouvoir changer)

gnuuat a écrit :

J'ai peut être mal compris (un bout de code serait plus explicite), mais il me semble que tu continues sur la logique du premier paragraphe, à savoir le fait qu'on est obligé de passer le pointeur de manière explicite pour pouvoir bénéficier de l'accès aux attributs et aux méthodes de l'objet...

Pas exactement, ou alors j'ai mal compris ce que toi tu veux dire.

Ce que je veux dire par là, c'est qu'il est nécessaire de préciser à un endroit ou à un autre sur quel objet tu appelles la méthode désirée, sinon il n'aurait aucun moyen de savoir sur quel objet l'appeler. Partant de là, il y a essentiellement deux manières de procéder : la version pseudo-C, « fonction(objet, parametres) » et la version objet classique « objet.fonction(paramètres) ».
Or, la version objet classique peut présenter un léger problème dans les cas d'héritages : en appelant « objet.fonction() », on fait appel à la méthode « fonction() » telle qu'elle est actuellement définie sur l'objet en question, donc si la classe à laquelle appartient cet objet redéfinit l'une des méthodes de sa classe mère, on a accès à la méthode de la classe fille et plus à celle de la classe mère.
Ce qui peut être assez problématique dans la mesure où on peut avoir besoin, à l'intérieur du code d'une classe fille, de faire appel au code de sa classe mère (l'exemple le plus fréquent étant le constructeur : on commence par faire appel au constructeur de la classe mère, puis on effectue les opérations supplémentaires pour finir la construction d'un objet de classe fille).

Java résout ce problème en introduisant un mot-clef « super », qui permet d'obtenir une référence vers la classe mère. Ainsi, « super.fonction() » lance, sur l'objet considéré, un appel à la méthode « fonction() » telle que définie dans la classe mère et non pas telle que redéfinie dans la classe fille.
Mais ça marche en Java parce que Java ne supporte pas l'héritage multiple : si une même classe fille dérivait de deux classes mères différentes disposant toutes deux d'une méthode « fonction() », le mot-clef « super » ne pourrait pas permettre de déterminer à laquelle des deux faire appel.
Python supportant l'héritage multiple, il est donc nécessaire de procéder autrement.

Or, justement, l'avantage de procéder à la manière pseudo-C, c'est qu'on peut appeler une fonction précise et lui passer l'objet sur lequel elle doit s'appliquer plutôt que de devoir aller chercher cette fonction dans l'objet lui-même.
En clair, grâce à l'utilisation de self comme premier paramètre, je peux appeler une méthode sur un objet à partir du nom de la classe désirée, ce qui permet d'indiquer explicitement à quelle méthode parente je fais référence.

En code :

class Machin(Truc, Bidule):
    # Plein de code ici…
    def meth(self, params):
        if (self.condition):
            Truc.meth(self, params)
        else:
            Bidule.meth(self, params)

On peut ainsi spécifier facilement à quelle super-classe on fait référence quand on veut accéder à une méthode qui a été redéfinie dans la classe fille.

Je précise que je n'ai jamais rencontré ce cas, et que ce n'est peut-être pas la justification première de cette manière de procéder, mais c'est ce qui m'apparaît le plus logique pour expliquer en quoi ce mode de fonctionnement est utile.

gnuuat · Le 16/01/2011, à 16:52

Ton explication est assez intéressante .
Par contre, ça m'étonne, car jusqu'ici il me semblait qu'on ne pouvait fournir explicitement ce paramètre lors de l'appel d'une méthode.

Elzen · Le 16/01/2011, à 17:32

On peut le fournir explicitement en préfixant le nom de la méthode de celui de la classe, plutôt que de celui de l'objet sur lequel on veut l'appeler, comme je fais ici avec Truc.meth(self) et Bidule.meth(self) au lieu de self.meth()

On le rencontre plus ou moins fréquemment dans les cas d'héritages, notamment pour le constructeur. Par exemple, si on veut définir un nouveau Widget utilisable en PyGTK, le début du code sera très probablement

class MyExtraWidget(gtk.Widget):
    def __init__(self):
        gtk.Widget.__init__(self)
        # etc.…

De cette manière, lors de l'appel au constructeur d'un objet de type MyExtraWidget, on commence par appeler sur lui le contructeur de gtk.Widget, qui permet ensuite aux différents conteneurs et autres éléments qui vont devoir le manipuler d'avoir les informations requises pour ceci.

C'est en cherchant comment faire ça que j'ai découvert ce type de fonctionnement.

Кຼزດ · Le 16/01/2011, à 22:16

Bon, j'ai enfin décidé de passer un énorme if/elseif/else en dict + methodes, et ya pas à dire, lambda c'est pratique…

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1226 Le 16/01/2011, à 03:10

Re : /* Topic des codeurs couche-tard [3] */

#1227 Le 16/01/2011, à 03:10

Re : /* Topic des codeurs couche-tard [3] */

#1228 Le 16/01/2011, à 03:15

Re : /* Topic des codeurs couche-tard [3] */

#1229 Le 16/01/2011, à 03:32

Re : /* Topic des codeurs couche-tard [3] */

#1230 Le 16/01/2011, à 04:10

Re : /* Topic des codeurs couche-tard [3] */

#1231 Le 16/01/2011, à 07:42

Re : /* Topic des codeurs couche-tard [3] */

#1232 Le 16/01/2011, à 07:42

Re : /* Topic des codeurs couche-tard [3] */

#1233 Le 16/01/2011, à 08:46

Re : /* Topic des codeurs couche-tard [3] */

#1234 Le 16/01/2011, à 09:46

Re : /* Topic des codeurs couche-tard [3] */

#1235 Le 16/01/2011, à 10:13

Re : /* Topic des codeurs couche-tard [3] */

#1236 Le 16/01/2011, à 10:17

Re : /* Topic des codeurs couche-tard [3] */

#1237 Le 16/01/2011, à 10:33

Re : /* Topic des codeurs couche-tard [3] */

#1238 Le 16/01/2011, à 10:43

Re : /* Topic des codeurs couche-tard [3] */

#1239 Le 16/01/2011, à 10:47

Re : /* Topic des codeurs couche-tard [3] */

#1240 Le 16/01/2011, à 11:53

Re : /* Topic des codeurs couche-tard [3] */

#1241 Le 16/01/2011, à 12:03

Re : /* Topic des codeurs couche-tard [3] */

#1242 Le 16/01/2011, à 12:25

Re : /* Topic des codeurs couche-tard [3] */

#1243 Le 16/01/2011, à 12:30

Re : /* Topic des codeurs couche-tard [3] */

#1244 Le 16/01/2011, à 12:37

Re : /* Topic des codeurs couche-tard [3] */

#1245 Le 16/01/2011, à 15:15

Re : /* Topic des codeurs couche-tard [3] */

#1246 Le 16/01/2011, à 15:19

Re : /* Topic des codeurs couche-tard [3] */

#1247 Le 16/01/2011, à 15:42

Re : /* Topic des codeurs couche-tard [3] */

#1248 Le 16/01/2011, à 16:52

Re : /* Topic des codeurs couche-tard [3] */

#1249 Le 16/01/2011, à 17:32

Re : /* Topic des codeurs couche-tard [3] */

#1250 Le 16/01/2011, à 22:16

Re : /* Topic des codeurs couche-tard [3] */

Pied de page des forums