Il y a un truc que j'ai du mal à saisir en Python : parfois, il y a
des types (date, par exemple), parfois il y a des classes (Decimal,
par exemple). On les repère par leur casse, très bien.
Mais je n'arrive pas à comprendre la logique/cohérence là-dedans : je
veux dire, pourquoi date n'est pas une classe ? c'est quand même
typiquement une abstraction au même sens que Decimal, non ? (je parle
de date, et de Decimal mais il y a une brouettée d'autres exemples).
Si on pouvait m'expliquer la justification de tout ça, je suis preneur
parce que, là, je trouve ça lourd d'être obligé de systématiquement me
poser la question à chaque fois que j'ai besoin d'un objet.
--
Eric Jacoboni, ne il y a 1436746622 secondes
Perso, j'ai pesté contre Java car leurs méthodes d'accès aux éléments types séquences n'étaient pas homogènes - et je pense qu'avoir à se replonger à chaque fois dans une doc pour savoir s'il faut passer par un itérateur ou bien récupérer la taille et manipuler un index - c'est vraiment galère, idem d'avoir X types de données (sûrement tout à fait justifiés) pour faire presque la même chose.
Oui, mais là on ne parle pas de la même chose...
Par ailleurs, si, les méthodes d'accès sont homogènes... pour autant que l'on soit d'accord avec la conception des classes de l'API des collections. C'est un peu hors sujet, mais m'est avis que ton problème vient du fait que tu lis l'arborescence de classes à l'envers, en partant des feuilles (classes concrètes), alors qu'il faut la lire en partant du haut, des interfaces, car ce sont elles qui indiquent finalement ce que tu es en droit d'attendre d'une classe.
L'interface List impose la manipulation par indices dans son contrat d'implémentation. Elle hérite de l'interface Collection qui, elle, impose iterator() dans son contrat.
Donc une classe qui implémente List peut être manipulée par indices ou par itérateurs. Une classe implémentant Collection mais pas List ne peut être manipulée que par des itérateurs (si l'on ne s'en tient ici qu'aux aspects de Collection et de List, mais il y en a d'autres).
C'est une présentation grossière (imparfaite et parfaitement hors thème) mais c'était juste pour bien indiquer qu'il ne s'agit pas de la problématique que je soulevais : dans la mienne, je n'évoquais pas de sémantique, mais uniquement un point syntaxique.
Perso, j'ai pesté contre Java car leurs méthodes d'accès aux éléments
types séquences n'étaient pas homogènes - et je pense qu'avoir à se
replonger à chaque fois dans une doc pour savoir s'il faut passer par un
itérateur ou bien récupérer la taille et manipuler un index - c'est
vraiment galère, idem d'avoir X types de données (sûrement tout à fait
justifiés) pour faire presque la même chose.
Oui, mais là on ne parle pas de la même chose...
Par ailleurs, si, les méthodes d'accès sont homogènes... pour autant
que l'on soit d'accord avec la conception des classes de l'API des
collections. C'est un peu hors sujet, mais m'est avis que ton problème
vient du fait que tu lis l'arborescence de classes à l'envers, en
partant des feuilles (classes concrètes), alors qu'il faut la lire en
partant du haut, des interfaces, car ce sont elles qui indiquent
finalement ce que tu es en droit d'attendre d'une classe.
L'interface List impose la manipulation par indices dans son contrat
d'implémentation. Elle hérite de l'interface Collection qui, elle, impose
iterator() dans son contrat.
Donc une classe qui implémente List peut être manipulée par indices ou
par itérateurs. Une classe implémentant Collection mais pas List ne
peut être manipulée que par des itérateurs (si l'on ne s'en tient ici
qu'aux aspects de Collection et de List, mais il y en a d'autres).
C'est une présentation grossière (imparfaite et parfaitement hors
thème) mais c'était juste pour bien indiquer qu'il ne s'agit pas de la
problématique que je soulevais : dans la mienne, je n'évoquais pas de
sémantique, mais uniquement un point syntaxique.
Perso, j'ai pesté contre Java car leurs méthodes d'accès aux éléments types séquences n'étaient pas homogènes - et je pense qu'avoir à se replonger à chaque fois dans une doc pour savoir s'il faut passer par un itérateur ou bien récupérer la taille et manipuler un index - c'est vraiment galère, idem d'avoir X types de données (sûrement tout à fait justifiés) pour faire presque la même chose.
Oui, mais là on ne parle pas de la même chose...
Par ailleurs, si, les méthodes d'accès sont homogènes... pour autant que l'on soit d'accord avec la conception des classes de l'API des collections. C'est un peu hors sujet, mais m'est avis que ton problème vient du fait que tu lis l'arborescence de classes à l'envers, en partant des feuilles (classes concrètes), alors qu'il faut la lire en partant du haut, des interfaces, car ce sont elles qui indiquent finalement ce que tu es en droit d'attendre d'une classe.
L'interface List impose la manipulation par indices dans son contrat d'implémentation. Elle hérite de l'interface Collection qui, elle, impose iterator() dans son contrat.
Donc une classe qui implémente List peut être manipulée par indices ou par itérateurs. Une classe implémentant Collection mais pas List ne peut être manipulée que par des itérateurs (si l'on ne s'en tient ici qu'aux aspects de Collection et de List, mais il y en a d'autres).
C'est une présentation grossière (imparfaite et parfaitement hors thème) mais c'était juste pour bien indiquer qu'il ne s'agit pas de la problématique que je soulevais : dans la mienne, je n'évoquais pas de sémantique, mais uniquement un point syntaxique.
bruno at modulix
Eric Jacoboni wrote:
bruno at modulix writes:
[désolé pour le lag, mais je suis en panne d'adéesseelle chez moi :( ]
Condoléances !-)
C'est ce je craignais... mais si c'est historique, pourquoi les évolutions du langage n'ont pas intégré de wrappers pour unifier l'existant ?
Bonne question. Peut-être pour éviter de casser du code existant ? Faire évoluer un langage dans tout casser n'est pas une chose aisée - à moins qu'il n'y ait pas d'utilisateurs du langage, bien sûr. Quand l'évolution touche à quelque chose d'aussi essentiel que la représentation interne, c'est encore plus délicat.
C'était bien dans cette optique que je parlais de wrapper... faire de Date un alias de date, de DateTime un alias de datetime...
Bin oui, mais s'il y a déjà du code qui utilise Date ou DateTime pour un type utilisateur ?-)
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Eric Jacoboni wrote:
bruno at modulix <onurb@xiludom.gro> writes:
[désolé pour le lag, mais je suis en panne d'adéesseelle chez moi :( ]
Condoléances !-)
C'est ce je craignais... mais si c'est historique, pourquoi les
évolutions du langage n'ont pas intégré de wrappers pour unifier
l'existant ?
Bonne question. Peut-être pour éviter de casser du code existant ?
Faire évoluer un langage dans tout casser n'est pas une chose aisée - à
moins qu'il n'y ait pas d'utilisateurs du langage, bien sûr. Quand
l'évolution touche à quelque chose d'aussi essentiel que la
représentation interne, c'est encore plus délicat.
C'était bien dans cette optique que je parlais de wrapper... faire de
Date un alias de date, de DateTime un alias de datetime...
Bin oui, mais s'il y a déjà du code qui utilise Date ou DateTime pour un
type utilisateur ?-)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
[désolé pour le lag, mais je suis en panne d'adéesseelle chez moi :( ]
Condoléances !-)
C'est ce je craignais... mais si c'est historique, pourquoi les évolutions du langage n'ont pas intégré de wrappers pour unifier l'existant ?
Bonne question. Peut-être pour éviter de casser du code existant ? Faire évoluer un langage dans tout casser n'est pas une chose aisée - à moins qu'il n'y ait pas d'utilisateurs du langage, bien sûr. Quand l'évolution touche à quelque chose d'aussi essentiel que la représentation interne, c'est encore plus délicat.
C'était bien dans cette optique que je parlais de wrapper... faire de Date un alias de date, de DateTime un alias de datetime...
Bin oui, mais s'il y a déjà du code qui utilise Date ou DateTime pour un type utilisateur ?-)
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Eric Jacoboni
bruno at modulix writes:
Bin oui, mais s'il y a déjà du code qui utilise Date ou DateTime pour un type utilisateur ?-)
Certes, mais c'est le même problème quand on introduit une nouvelle classe (decimal, à moins que ce ne soit Decimal... groumpf), non ?
bruno at modulix <onurb@xiludom.gro> writes:
Bin oui, mais s'il y a déjà du code qui utilise Date ou DateTime pour un
type utilisateur ?-)
Certes, mais c'est le même problème quand on introduit une nouvelle
classe (decimal, à moins que ce ne soit Decimal... groumpf), non ?
Bin oui, mais s'il y a déjà du code qui utilise Date ou DateTime pour un type utilisateur ?-)
Certes, mais c'est le même problème quand on introduit une nouvelle classe (decimal, à moins que ce ne soit Decimal... groumpf), non ?
Encolpe Degoute
bruno at modulix writes:
Je ne vois pas pourquoi on *obligerait* à indenter alors qu'on n'oblige pas à respecter une casse, ce n'est pas cohérent.
Tu va un peu vite, là. je suis d'accord sur le fait qu'il n'est pas forcément plus idiot d'intégrer cette règle dans la grammaire que celle concernant l'indentation, mais je ne vois absolument pas en quoi faire l'autre sans l'un (ou l'un sans l'autre) serait "incohérent".
Parce que, selon moi, si l'on impose une certaine syntaxe dans le layout d'un programme, la cohérence voudrait que l'on impose également une certaine discipline dans la syntaxe. C'est ce que fait Haskell, par exemple. Pour moi « incohérent », ça signifie exactement ça, pas plus..
+42
Le pire est quand même d'avoir autorisé le mixage des tabulations et des espaces dans l'indentation...
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
bruno at modulix <onurb@xiludom.gro> writes:
Je ne vois pas pourquoi on *obligerait* à indenter alors qu'on
n'oblige pas à respecter une casse, ce n'est pas cohérent.
Tu va un peu vite, là. je suis d'accord sur le fait qu'il n'est pas
forcément plus idiot d'intégrer cette règle dans la grammaire que celle
concernant l'indentation, mais je ne vois absolument pas en quoi faire
l'autre sans l'un (ou l'un sans l'autre) serait "incohérent".
Parce que, selon moi, si l'on impose une certaine syntaxe dans le
layout d'un programme, la cohérence voudrait que l'on impose également
une certaine discipline dans la syntaxe. C'est ce que fait Haskell,
par exemple. Pour moi « incohérent », ça signifie exactement ça, pas
plus..
+42
Le pire est quand même d'avoir autorisé le mixage des tabulations et des
espaces dans l'indentation...
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
Je ne vois pas pourquoi on *obligerait* à indenter alors qu'on n'oblige pas à respecter une casse, ce n'est pas cohérent.
Tu va un peu vite, là. je suis d'accord sur le fait qu'il n'est pas forcément plus idiot d'intégrer cette règle dans la grammaire que celle concernant l'indentation, mais je ne vois absolument pas en quoi faire l'autre sans l'un (ou l'un sans l'autre) serait "incohérent".
Parce que, selon moi, si l'on impose une certaine syntaxe dans le layout d'un programme, la cohérence voudrait que l'on impose également une certaine discipline dans la syntaxe. C'est ce que fait Haskell, par exemple. Pour moi « incohérent », ça signifie exactement ça, pas plus..
+42
Le pire est quand même d'avoir autorisé le mixage des tabulations et des espaces dans l'indentation...
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
bruno at modulix
Eric Jacoboni wrote:
bruno at modulix writes:
Bin oui, mais s'il y a déjà du code qui utilise Date ou DateTime pour un type utilisateur ?-)
Certes, mais c'est le même problème quand on introduit une nouvelle classe (decimal, à moins que ce ne soit Decimal... groumpf), non ?
Oui, effectivement.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Eric Jacoboni wrote:
bruno at modulix <onurb@xiludom.gro> writes:
Bin oui, mais s'il y a déjà du code qui utilise Date ou DateTime pour un
type utilisateur ?-)
Certes, mais c'est le même problème quand on introduit une nouvelle
classe (decimal, à moins que ce ne soit Decimal... groumpf), non ?
Oui, effectivement.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
