Dans le cadre de ma décision "j'apprends à coder proprement et
efficacement", j'ai 2.5 questions à vous poser (ça ne fait que commencer
:)).
Tout d'abord, pourquoi ne peut-on pas faire :
$a = (explode("?",$string))[0];
puisque explode renvoie un array ?
Ensuite, pourquoi ceci ne fonctionne pas :
array_flip($a);
ni même :
array_flip(&$a);
On est donc forcé d'écrire :
$a = array_flip($a);
?
La demi-question : Est-il (vraiment) utile de faire un unset dès que
l'on a plus besoin d'une variable si cette variable ne contient pas des
tonnes de données ?
Petite anecdote : hier en cherchant si qq un avait déjà codé ce que je
voulais, je suis tombé sur une solution.
Elle est publiée sur le site d'une agence web. Bon.
Cette solution fait 50 lignes, qui ressemblent à s'y méprendre à du
visualbasic codé par un enfant de 10ans.
Voyant ça, j'ai cherché de mon côté pour, au final, arriver à un
meilleur résultat en... 5 lignes (et 15 minutes de recherche dans le doc
php) !
Jusque là, vous me direz, c'est commun dans le monde du web. Sauf que
cette agence à créer son CMS en PHP :) (et là, c'est le drame).
Je ne veux pas devenir comme ça ! Alors je pose des questions :)
Et comme d'hab, c'est sympa de votre part d'y répondre.
Certaines fonctionnalités sont tellement spécifiques à un projet qu'il serait effectivement inepte de vouloir les rendre générique. D'autre, par contre, correspondent à des besoins récurrents, et il est parfois très simple de les rendre tout de suite suffisament générique pour couvrir la majorité des cas d'utilisation. C'est ici le cas, et l'"effort" nécessaire est tellement dérisoire (deux lignes de code et 15 secondes de réflexion....) qu'il est AMHA dommage de ne pas l'avoir fait immédiatement.
Je comprends tout à fait ton raisonnement... qui est celui qui m'a jadis fait perdre des heures.
Been here, done that...
Car il est toujours très délicat de déterminer ce qui pourra être utile, si toutefois c'est utile un jour.
Mmmm... Disons qu'avec l'expérience, certains cas relèvent de l'évidence - dans un sens comme dans l'autre. Pour moi (c'est à dire "à mon avis, qui m'est éminemment personnel et que je ne force personne à partager - tant que je n'ai pas à maintenir le code"), le cas ci-dessus relève de l'évidence, mais bon, hein... C'est pas mon appli, n'est-ce pas !-)
Donc dans le cas que tu cites, ok, mais moi j'ai la flemme d'ajouter un argument à chaque fois.
Utilise un argument avec une valeur par défaut. Bon, c'est vrai qu'en PHP y a pas d'arguments nommés, donc c'est un peu plus ch...
Eh, tu postes ton code, je cherche la petite bête, hein ?-)
(snip)
J'imagine la tonne de commentaires négatifs si j'avais posté tout le bloc :)
"négatifs" ???
Mais en fait, c'est comme ça que l'on devrait apprendre.
On apprend toujours d'une revue de code - dans un sens comme dans l'autre (je veux dire, qu'on soit la victime ou le bourreau <g>), et quelques soient l'expérience, le niveau et le background.
Olivier Masson a écrit :
Bruno Desthuilliers a écrit :
Certaines fonctionnalités sont tellement spécifiques à un projet qu'il
serait effectivement inepte de vouloir les rendre générique. D'autre,
par contre, correspondent à des besoins récurrents, et il est parfois
très simple de les rendre tout de suite suffisament générique pour
couvrir la majorité des cas d'utilisation. C'est ici le cas, et
l'"effort" nécessaire est tellement dérisoire (deux lignes de code et 15
secondes de réflexion....) qu'il est AMHA dommage de ne pas l'avoir fait
immédiatement.
Je comprends tout à fait ton raisonnement... qui est celui qui m'a jadis
fait perdre des heures.
Been here, done that...
Car il est toujours très délicat de déterminer
ce qui pourra être utile, si toutefois c'est utile un jour.
Mmmm... Disons qu'avec l'expérience, certains cas relèvent de l'évidence
- dans un sens comme dans l'autre. Pour moi (c'est à dire "à mon avis,
qui m'est éminemment personnel et que je ne force personne à partager -
tant que je n'ai pas à maintenir le code"), le cas ci-dessus relève de
l'évidence, mais bon, hein... C'est pas mon appli, n'est-ce pas !-)
Donc dans le cas que tu cites, ok, mais moi j'ai la flemme d'ajouter un
argument à chaque fois.
Utilise un argument avec une valeur par défaut. Bon, c'est vrai qu'en
PHP y a pas d'arguments nommés, donc c'est un peu plus ch...
Eh, tu postes ton code, je cherche la petite bête, hein ?-)
(snip)
J'imagine la tonne de commentaires négatifs si j'avais posté tout le
bloc :)
"négatifs" ???
Mais en fait, c'est comme ça que l'on devrait apprendre.
On apprend toujours d'une revue de code - dans un sens comme dans
l'autre (je veux dire, qu'on soit la victime ou le bourreau <g>), et
quelques soient l'expérience, le niveau et le background.
Certaines fonctionnalités sont tellement spécifiques à un projet qu'il serait effectivement inepte de vouloir les rendre générique. D'autre, par contre, correspondent à des besoins récurrents, et il est parfois très simple de les rendre tout de suite suffisament générique pour couvrir la majorité des cas d'utilisation. C'est ici le cas, et l'"effort" nécessaire est tellement dérisoire (deux lignes de code et 15 secondes de réflexion....) qu'il est AMHA dommage de ne pas l'avoir fait immédiatement.
Je comprends tout à fait ton raisonnement... qui est celui qui m'a jadis fait perdre des heures.
Been here, done that...
Car il est toujours très délicat de déterminer ce qui pourra être utile, si toutefois c'est utile un jour.
Mmmm... Disons qu'avec l'expérience, certains cas relèvent de l'évidence - dans un sens comme dans l'autre. Pour moi (c'est à dire "à mon avis, qui m'est éminemment personnel et que je ne force personne à partager - tant que je n'ai pas à maintenir le code"), le cas ci-dessus relève de l'évidence, mais bon, hein... C'est pas mon appli, n'est-ce pas !-)
Donc dans le cas que tu cites, ok, mais moi j'ai la flemme d'ajouter un argument à chaque fois.
Utilise un argument avec une valeur par défaut. Bon, c'est vrai qu'en PHP y a pas d'arguments nommés, donc c'est un peu plus ch...
Eh, tu postes ton code, je cherche la petite bête, hein ?-)
(snip)
J'imagine la tonne de commentaires négatifs si j'avais posté tout le bloc :)
"négatifs" ???
Mais en fait, c'est comme ça que l'on devrait apprendre.
On apprend toujours d'une revue de code - dans un sens comme dans l'autre (je veux dire, qu'on soit la victime ou le bourreau <g>), et quelques soient l'expérience, le niveau et le background.
Bruno Desthuilliers
Olivier Masson a écrit :
Olivier Miakinen a écrit :
Le 05/11/2009 21:12, Mickaël Wolff a écrit :
Pas seulement. Si tu savais les horreurs que j'ai vu dans des applis de gestion...
Comme l'usage des float pour gérer les flux monétaires ?
Trouvé sur le « daily WTF » francophone : http://img.thedailywtf.com/images/fr/errors/bateau.JPG
Vous utilisez quoi pour les sous alors ?
des décimaux ou des entiers, selon le contexte.
Mais bon, je ne gère pas les échanges de devises sur lesquelles un cercle de gens puants (oups, HS) peuvent se faire un max sur un changement de la 4eme décimales.
De simples calculs TTC / HT, remises (fixe / pourcentage), frais de port, tati pouffin - bref, des trucs que tu va trouver dans n'importe quelle appli de gestion commerciale, de commerce en ligne, de paie, etc, suffisent à fausser le résultat.
Olivier Masson a écrit :
Olivier Miakinen a écrit :
Le 05/11/2009 21:12, Mickaël Wolff a écrit :
Pas seulement. Si tu savais les horreurs que j'ai vu dans des applis
de gestion...
Comme l'usage des float pour gérer les flux monétaires ?
Trouvé sur le « daily WTF » francophone :
http://img.thedailywtf.com/images/fr/errors/bateau.JPG
Vous utilisez quoi pour les sous alors ?
des décimaux ou des entiers, selon le contexte.
Mais bon, je ne gère pas les échanges de devises sur lesquelles un
cercle de gens puants (oups, HS) peuvent se faire un max sur un
changement de la 4eme décimales.
De simples calculs TTC / HT, remises (fixe / pourcentage), frais de
port, tati pouffin - bref, des trucs que tu va trouver dans n'importe
quelle appli de gestion commerciale, de commerce en ligne, de paie, etc,
suffisent à fausser le résultat.
Pas seulement. Si tu savais les horreurs que j'ai vu dans des applis de gestion...
Comme l'usage des float pour gérer les flux monétaires ?
Trouvé sur le « daily WTF » francophone : http://img.thedailywtf.com/images/fr/errors/bateau.JPG
Vous utilisez quoi pour les sous alors ?
des décimaux ou des entiers, selon le contexte.
Mais bon, je ne gère pas les échanges de devises sur lesquelles un cercle de gens puants (oups, HS) peuvent se faire un max sur un changement de la 4eme décimales.
De simples calculs TTC / HT, remises (fixe / pourcentage), frais de port, tati pouffin - bref, des trucs que tu va trouver dans n'importe quelle appli de gestion commerciale, de commerce en ligne, de paie, etc, suffisent à fausser le résultat.
Olivier Masson
Mickaël Wolff a écrit :
Concrètement, ANSI SQL propose un type précis : DECIMAL. MySQL le supporte et garanti le comportement du DECIMAL. Du coup, je fais tout les calculs dans MySQL.
Ok, c'est une bonne idée.
Si tu n'as pas de bases de données, il existe des bibliothèques qui fournissent cette fonctionnalité (au hasard, GMP qui est disponible dans PHP).
Merci.
Mickaël Wolff a écrit :
Concrètement, ANSI SQL propose un type précis : DECIMAL. MySQL le
supporte et garanti le comportement du DECIMAL. Du coup, je fais tout
les calculs dans MySQL.
Ok, c'est une bonne idée.
Si tu n'as pas de bases de données, il existe des bibliothèques qui
fournissent cette fonctionnalité (au hasard, GMP qui est disponible dans
PHP).
Concrètement, ANSI SQL propose un type précis : DECIMAL. MySQL le supporte et garanti le comportement du DECIMAL. Du coup, je fais tout les calculs dans MySQL.
Ok, c'est une bonne idée.
Si tu n'as pas de bases de données, il existe des bibliothèques qui fournissent cette fonctionnalité (au hasard, GMP qui est disponible dans PHP).
Merci.
Olivier Masson
Bruno Desthuilliers a écrit :
Olivier Masson a écrit :
Je comprends tout à fait ton raisonnement... qui est celui qui m'a jadis fait perdre des heures.
Been here, done that...
Tu ne crois pas si bien dire ! Même si je ne suis pas développeur, je "programmais" sur mon Sharp puis mon Commodore. Comme j'ai préféré avoir une vie sociale, j'ai laissé tomber 10 ans durant... mais j'ai eu du mal ensuite à me défaire de certaines vieilles habitudes comme d'optimiser la moindre milliseconde au traitement (ça comptait quand je sortais des Mandelbrot ou des Lyapunov sur l'Amiga !) Le mieux est l'ennemi du bien.
Utilise un argument avec une valeur par défaut. Bon, c'est vrai qu'en PHP y a pas d'arguments nommés, donc c'est un peu plus ch...
Oui, c'est ce que j'ai fait au final... mais non en fait :/ puisque "Qu'est-ce qu'un argument nommé ?".
J'imagine la tonne de commentaires négatifs si j'avais posté tout le bloc :)
"négatifs" ???
Ce que je veux dire c'est que je ne m'attends pas à des applaudissements en mettant mon code ici :)
Bruno Desthuilliers a écrit :
Olivier Masson a écrit :
Je comprends tout à fait ton raisonnement... qui est celui qui m'a
jadis fait perdre des heures.
Been here, done that...
Tu ne crois pas si bien dire ! Même si je ne suis pas développeur, je
"programmais" sur mon Sharp puis mon Commodore. Comme j'ai préféré avoir
une vie sociale, j'ai laissé tomber 10 ans durant... mais j'ai eu du mal
ensuite à me défaire de certaines vieilles habitudes comme d'optimiser
la moindre milliseconde au traitement (ça comptait quand je sortais des
Mandelbrot ou des Lyapunov sur l'Amiga !)
Le mieux est l'ennemi du bien.
Utilise un argument avec une valeur par défaut. Bon, c'est vrai qu'en
PHP y a pas d'arguments nommés, donc c'est un peu plus ch...
Oui, c'est ce que j'ai fait au final... mais non en fait :/ puisque
"Qu'est-ce qu'un argument nommé ?".
J'imagine la tonne de commentaires négatifs si j'avais posté tout le
bloc :)
"négatifs" ???
Ce que je veux dire c'est que je ne m'attends pas à des applaudissements
en mettant mon code ici :)
Je comprends tout à fait ton raisonnement... qui est celui qui m'a jadis fait perdre des heures.
Been here, done that...
Tu ne crois pas si bien dire ! Même si je ne suis pas développeur, je "programmais" sur mon Sharp puis mon Commodore. Comme j'ai préféré avoir une vie sociale, j'ai laissé tomber 10 ans durant... mais j'ai eu du mal ensuite à me défaire de certaines vieilles habitudes comme d'optimiser la moindre milliseconde au traitement (ça comptait quand je sortais des Mandelbrot ou des Lyapunov sur l'Amiga !) Le mieux est l'ennemi du bien.
Utilise un argument avec une valeur par défaut. Bon, c'est vrai qu'en PHP y a pas d'arguments nommés, donc c'est un peu plus ch...
Oui, c'est ce que j'ai fait au final... mais non en fait :/ puisque "Qu'est-ce qu'un argument nommé ?".
J'imagine la tonne de commentaires négatifs si j'avais posté tout le bloc :)
"négatifs" ???
Ce que je veux dire c'est que je ne m'attends pas à des applaudissements en mettant mon code ici :)
Bruno Desthuilliers
Olivier Masson a écrit :
Bruno Desthuilliers a écrit :
(snip)
Utilise un argument avec une valeur par défaut. Bon, c'est vrai qu'en PHP y a pas d'arguments nommés, donc c'est un peu plus ch...
Oui, c'est ce que j'ai fait au final... mais non en fait :/ puisque "Qu'est-ce qu'un argument nommé ?".
Certains langages permettent de passer les arguments "dans le désordre" en les nommant explicitement lors de l'appel. Par exemple, la fonction:
def func(arg1, arg2, arg3): # code here
peut être appelée ainsi:
func(arg3B, arg1="yadda", arg2="whatever")
C'est très pratique pour une fonction comme la tienne où il y a plusieurs arguments avec des valeurs par défaut, en ce que ça évite de devoir passer explicitement ceux des arguments pour lesquels tu veux conserver la valeur par défaut.
J'imagine la tonne de commentaires négatifs si j'avais posté tout le bloc :)
"négatifs" ???
Ce que je veux dire c'est que je ne m'attends pas à des applaudissements en mettant mon code ici :)
Oh bin c'en était pas loin pourtant. Il a vraiment fallu que je cherche la petite bête !-)
Olivier Masson a écrit :
Bruno Desthuilliers a écrit :
(snip)
Utilise un argument avec une valeur par défaut. Bon, c'est vrai qu'en
PHP y a pas d'arguments nommés, donc c'est un peu plus ch...
Oui, c'est ce que j'ai fait au final... mais non en fait :/ puisque
"Qu'est-ce qu'un argument nommé ?".
Certains langages permettent de passer les arguments "dans le désordre"
en les nommant explicitement lors de l'appel. Par exemple, la fonction:
def func(arg1, arg2, arg3):
# code here
peut être appelée ainsi:
func(arg3B, arg1="yadda", arg2="whatever")
C'est très pratique pour une fonction comme la tienne où il y a
plusieurs arguments avec des valeurs par défaut, en ce que ça évite de
devoir passer explicitement ceux des arguments pour lesquels tu veux
conserver la valeur par défaut.
J'imagine la tonne de commentaires négatifs si j'avais posté tout le
bloc :)
"négatifs" ???
Ce que je veux dire c'est que je ne m'attends pas à des applaudissements
en mettant mon code ici :)
Oh bin c'en était pas loin pourtant. Il a vraiment fallu que je cherche
la petite bête !-)
Utilise un argument avec une valeur par défaut. Bon, c'est vrai qu'en PHP y a pas d'arguments nommés, donc c'est un peu plus ch...
Oui, c'est ce que j'ai fait au final... mais non en fait :/ puisque "Qu'est-ce qu'un argument nommé ?".
Certains langages permettent de passer les arguments "dans le désordre" en les nommant explicitement lors de l'appel. Par exemple, la fonction:
def func(arg1, arg2, arg3): # code here
peut être appelée ainsi:
func(arg3B, arg1="yadda", arg2="whatever")
C'est très pratique pour une fonction comme la tienne où il y a plusieurs arguments avec des valeurs par défaut, en ce que ça évite de devoir passer explicitement ceux des arguments pour lesquels tu veux conserver la valeur par défaut.
J'imagine la tonne de commentaires négatifs si j'avais posté tout le bloc :)
"négatifs" ???
Ce que je veux dire c'est que je ne m'attends pas à des applaudissements en mettant mon code ici :)
Oh bin c'en était pas loin pourtant. Il a vraiment fallu que je cherche la petite bête !-)
Olivier Masson
Bruno Desthuilliers a écrit :
Certains langages permettent de passer les arguments "dans le désordre" en les nommant explicitement lors de l'appel. Par exemple, la fonction:
def func(arg1, arg2, arg3): # code here
peut être appelée ainsi:
func(arg3B, arg1="yadda", arg2="whatever")
En effet, c'est bien pratique !
Pour clore ce premier fil, tu disais que dans les langages OO, tout était objet. Mais concrètement - si tu as quelques minutes encore à me consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Bruno Desthuilliers a écrit :
Certains langages permettent de passer les arguments "dans le désordre"
en les nommant explicitement lors de l'appel. Par exemple, la fonction:
def func(arg1, arg2, arg3):
# code here
peut être appelée ainsi:
func(arg3B, arg1="yadda", arg2="whatever")
En effet, c'est bien pratique !
Pour clore ce premier fil, tu disais que dans les langages OO, tout
était objet. Mais concrètement - si tu as quelques minutes encore à me
consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Certains langages permettent de passer les arguments "dans le désordre" en les nommant explicitement lors de l'appel. Par exemple, la fonction:
def func(arg1, arg2, arg3): # code here
peut être appelée ainsi:
func(arg3B, arg1="yadda", arg2="whatever")
En effet, c'est bien pratique !
Pour clore ce premier fil, tu disais que dans les langages OO, tout était objet. Mais concrètement - si tu as quelques minutes encore à me consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Pascal
Olivier Masson a écrit :
Pour clore ce premier fil, tu disais que dans les langages OO, tout était objet. Mais concrètement - si tu as quelques minutes encore à me consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Si je puis me permettre de répondre, en admettant que PHP soit ce genre de langage, au lieu d'utiliser la fonction "in_array()", on pourrait invoquer la méthode correspondante d'un objet de type "Array".
Ça donnerait :
<?php // On crée un objet de type "Array", d'où l'opérateur "new". $tableau = new Array("tata", "momo", "lili"); // On teste l'existence d'un élément dans le tableau. $test = $tableau->in_array("riri"); // donne FALSE dans l'ex. ?>
Ce serait donc une écriture différente et, peut-être, offrirait une meilleure sémantique au codage.
Cordialement, Pascal
Olivier Masson a écrit :
Pour clore ce premier fil, tu disais que dans les langages OO, tout
était objet. Mais concrètement - si tu as quelques minutes encore à me
consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Si je puis me permettre de répondre, en admettant que PHP soit ce genre
de langage, au lieu d'utiliser la fonction "in_array()", on pourrait
invoquer la méthode correspondante d'un objet de type "Array".
Ça donnerait :
<?php
// On crée un objet de type "Array", d'où l'opérateur "new".
$tableau = new Array("tata", "momo", "lili");
// On teste l'existence d'un élément dans le tableau.
$test = $tableau->in_array("riri"); // donne FALSE dans l'ex.
?>
Ce serait donc une écriture différente et, peut-être, offrirait une
meilleure sémantique au codage.
Pour clore ce premier fil, tu disais que dans les langages OO, tout était objet. Mais concrètement - si tu as quelques minutes encore à me consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Si je puis me permettre de répondre, en admettant que PHP soit ce genre de langage, au lieu d'utiliser la fonction "in_array()", on pourrait invoquer la méthode correspondante d'un objet de type "Array".
Ça donnerait :
<?php // On crée un objet de type "Array", d'où l'opérateur "new". $tableau = new Array("tata", "momo", "lili"); // On teste l'existence d'un élément dans le tableau. $test = $tableau->in_array("riri"); // donne FALSE dans l'ex. ?>
Ce serait donc une écriture différente et, peut-être, offrirait une meilleure sémantique au codage.
Cordialement, Pascal
Bruno Desthuilliers
Olivier Masson a écrit :
Pour clore ce premier fil, tu disais que dans les langages OO, tout était objet.
Définition selon laquelle ni C++ ni Java ne sont des langages objets, puisque les deux ont des types non-objet !-)
Fais pas gaffe, je suis un peu extrémiste, des fois...
Mais concrètement - si tu as quelques minutes encore à me consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Dans l'absolu, à rien, pourquoi ?-)
Plus sérieusement, avoir un modèle à peu près uniforme simplifie nettement la vie - que ce soit un modèle objet ou non, d'ailleurs. Mais ce dont je parlais était plus de l'ordre d'une différence d'utilisation pratique induite par le fait que le langage soit _fondamentalement_ un langage objet ou non.
En Python ou en Ruby, il est naturel et évident d'utiliser des objets, puisque tout ce que tu peux manipuler est un forcément un objet[1].
En PHP, la surcouche objet est et reste une surcouche par dessus un langage fondamentalement procédural, et il plus naturel et évident (et, pour la plupart des besoins, plus efficace) d'utiliser une approche procédurale.
Accessoirement, le modèle objet de PHP est *très* loin derrière ceux de Ruby et Python en terme de fonctionnalités, de souplesse et de puissance. Ca tient un peu de la comparaison entre une trotinette et un missile balistique !-)
Accessoirement aussi, une architecture tout-objet (avec le surcoût que ça implique) n'est pas vraiment optimale dans le contexte du modèle d'exécution de PHP, où il faut reconstruire le mondre entier à chaque requête HTTP.
[1] Ca n'interdit pas (en Python au moins) d'avoir des fonctions "ordinaires", mais ces fonctions elles-mêmes sont des objets. Bref, Python ne force pas à tout mettre dans des classes (comme Java par exemple), et n'interdit pas de mixer procédural et OO (et même un peu de FP).
Olivier Masson a écrit :
Pour clore ce premier fil, tu disais que dans les langages OO, tout
était objet.
Définition selon laquelle ni C++ ni Java ne sont des langages objets,
puisque les deux ont des types non-objet !-)
Fais pas gaffe, je suis un peu extrémiste, des fois...
Mais concrètement - si tu as quelques minutes encore à me
consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Dans l'absolu, à rien, pourquoi ?-)
Plus sérieusement, avoir un modèle à peu près uniforme simplifie
nettement la vie - que ce soit un modèle objet ou non, d'ailleurs. Mais
ce dont je parlais était plus de l'ordre d'une différence d'utilisation
pratique induite par le fait que le langage soit _fondamentalement_ un
langage objet ou non.
En Python ou en Ruby, il est naturel et évident d'utiliser des objets,
puisque tout ce que tu peux manipuler est un forcément un objet[1].
En PHP, la surcouche objet est et reste une surcouche par dessus un
langage fondamentalement procédural, et il plus naturel et évident (et,
pour la plupart des besoins, plus efficace) d'utiliser une approche
procédurale.
Accessoirement, le modèle objet de PHP est *très* loin derrière ceux de
Ruby et Python en terme de fonctionnalités, de souplesse et de
puissance. Ca tient un peu de la comparaison entre une trotinette et un
missile balistique !-)
Accessoirement aussi, une architecture tout-objet (avec le surcoût que
ça implique) n'est pas vraiment optimale dans le contexte du modèle
d'exécution de PHP, où il faut reconstruire le mondre entier à chaque
requête HTTP.
[1] Ca n'interdit pas (en Python au moins) d'avoir des fonctions
"ordinaires", mais ces fonctions elles-mêmes sont des objets. Bref,
Python ne force pas à tout mettre dans des classes (comme Java par
exemple), et n'interdit pas de mixer procédural et OO (et même un peu de
FP).
Pour clore ce premier fil, tu disais que dans les langages OO, tout était objet.
Définition selon laquelle ni C++ ni Java ne sont des langages objets, puisque les deux ont des types non-objet !-)
Fais pas gaffe, je suis un peu extrémiste, des fois...
Mais concrètement - si tu as quelques minutes encore à me consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Dans l'absolu, à rien, pourquoi ?-)
Plus sérieusement, avoir un modèle à peu près uniforme simplifie nettement la vie - que ce soit un modèle objet ou non, d'ailleurs. Mais ce dont je parlais était plus de l'ordre d'une différence d'utilisation pratique induite par le fait que le langage soit _fondamentalement_ un langage objet ou non.
En Python ou en Ruby, il est naturel et évident d'utiliser des objets, puisque tout ce que tu peux manipuler est un forcément un objet[1].
En PHP, la surcouche objet est et reste une surcouche par dessus un langage fondamentalement procédural, et il plus naturel et évident (et, pour la plupart des besoins, plus efficace) d'utiliser une approche procédurale.
Accessoirement, le modèle objet de PHP est *très* loin derrière ceux de Ruby et Python en terme de fonctionnalités, de souplesse et de puissance. Ca tient un peu de la comparaison entre une trotinette et un missile balistique !-)
Accessoirement aussi, une architecture tout-objet (avec le surcoût que ça implique) n'est pas vraiment optimale dans le contexte du modèle d'exécution de PHP, où il faut reconstruire le mondre entier à chaque requête HTTP.
[1] Ca n'interdit pas (en Python au moins) d'avoir des fonctions "ordinaires", mais ces fonctions elles-mêmes sont des objets. Bref, Python ne force pas à tout mettre dans des classes (comme Java par exemple), et n'interdit pas de mixer procédural et OO (et même un peu de FP).
Bruno Desthuilliers
Pascal a écrit :
Olivier Masson a écrit :
Pour clore ce premier fil, tu disais que dans les langages OO, tout était objet. Mais concrètement - si tu as quelques minutes encore à me consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Si je puis me permettre de répondre, en admettant que PHP soit ce genre de langage, au lieu d'utiliser la fonction "in_array()", on pourrait invoquer la méthode correspondante d'un objet de type "Array".
Ça donnerait :
<?php // On crée un objet de type "Array", d'où l'opérateur "new". $tableau = new Array("tata", "momo", "lili"); // On teste l'existence d'un élément dans le tableau. $test = $tableau->in_array("riri"); // donne FALSE dans l'ex. ?>
Ou, pour aborder les choses à un plus haut niveau, on pourrait envisager un operateur 'in' qui fonctionne sur tout objet implémentant l'interface approprié, ce qui permettrait de ne pas se soucier du type exact de la "collection" utilisée (tableau ou autre). De même, on pourrait envisager une implémentation de foreach() qui permette d'itérer sur tout objet implémentant l'interface adéquate - idem, on gagne beaucoup en généricité.
Un des objectifs de l'OO est de découpler l'interface de l'implémentation. D'une part pour faciliter la maintenance (encapsulation), et d'autre part pour accroitre la généricité (polymorphisme).
Pascal a écrit :
Olivier Masson a écrit :
Pour clore ce premier fil, tu disais que dans les langages OO, tout
était objet. Mais concrètement - si tu as quelques minutes encore à me
consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Si je puis me permettre de répondre, en admettant que PHP soit ce genre
de langage, au lieu d'utiliser la fonction "in_array()", on pourrait
invoquer la méthode correspondante d'un objet de type "Array".
Ça donnerait :
<?php
// On crée un objet de type "Array", d'où l'opérateur "new".
$tableau = new Array("tata", "momo", "lili");
// On teste l'existence d'un élément dans le tableau.
$test = $tableau->in_array("riri"); // donne FALSE dans l'ex.
?>
Ou, pour aborder les choses à un plus haut niveau, on pourrait envisager
un operateur 'in' qui fonctionne sur tout objet implémentant
l'interface approprié, ce qui permettrait de ne pas se soucier du type
exact de la "collection" utilisée (tableau ou autre). De même, on
pourrait envisager une implémentation de foreach() qui permette d'itérer
sur tout objet implémentant l'interface adéquate - idem, on gagne
beaucoup en généricité.
Un des objectifs de l'OO est de découpler l'interface de
l'implémentation. D'une part pour faciliter la maintenance
(encapsulation), et d'autre part pour accroitre la généricité
(polymorphisme).
Pour clore ce premier fil, tu disais que dans les langages OO, tout était objet. Mais concrètement - si tu as quelques minutes encore à me consacrer -, ça sert à quoi qu'une variable, par exemple, soit un objet ?
Si je puis me permettre de répondre, en admettant que PHP soit ce genre de langage, au lieu d'utiliser la fonction "in_array()", on pourrait invoquer la méthode correspondante d'un objet de type "Array".
Ça donnerait :
<?php // On crée un objet de type "Array", d'où l'opérateur "new". $tableau = new Array("tata", "momo", "lili"); // On teste l'existence d'un élément dans le tableau. $test = $tableau->in_array("riri"); // donne FALSE dans l'ex. ?>
Ou, pour aborder les choses à un plus haut niveau, on pourrait envisager un operateur 'in' qui fonctionne sur tout objet implémentant l'interface approprié, ce qui permettrait de ne pas se soucier du type exact de la "collection" utilisée (tableau ou autre). De même, on pourrait envisager une implémentation de foreach() qui permette d'itérer sur tout objet implémentant l'interface adéquate - idem, on gagne beaucoup en généricité.
Un des objectifs de l'OO est de découpler l'interface de l'implémentation. D'une part pour faciliter la maintenance (encapsulation), et d'autre part pour accroitre la généricité (polymorphisme).
Olivier Masson
Bruno Desthuilliers a écrit :
[1] Ca n'interdit pas (en Python au moins) d'avoir des fonctions "ordinaires", mais ces fonctions elles-mêmes sont des objets. Bref, Python ne force pas à tout mettre dans des classes (comme Java par exemple), et n'interdit pas de mixer procédural et OO (et même un peu de FP).
ça explique pourquoi j'ai déjà fait des scripts Python sans trop voir de différences avec PHP :o)
Merci pour ces éclaircissements.
Bruno Desthuilliers a écrit :
[1] Ca n'interdit pas (en Python au moins) d'avoir des fonctions
"ordinaires", mais ces fonctions elles-mêmes sont des objets. Bref,
Python ne force pas à tout mettre dans des classes (comme Java par
exemple), et n'interdit pas de mixer procédural et OO (et même un peu de
FP).
ça explique pourquoi j'ai déjà fait des scripts Python sans trop voir de
différences avec PHP :o)
[1] Ca n'interdit pas (en Python au moins) d'avoir des fonctions "ordinaires", mais ces fonctions elles-mêmes sont des objets. Bref, Python ne force pas à tout mettre dans des classes (comme Java par exemple), et n'interdit pas de mixer procédural et OO (et même un peu de FP).
ça explique pourquoi j'ai déjà fait des scripts Python sans trop voir de différences avec PHP :o)
