Bonjour et Bonne ann=E9e =E0 tous.
Pour commencer l'ann=E9e, et comme l'hiver est d=E9j=E0 bien froid et risqu=
e
d'=EAtre long, je me suis mis =E0 la programmation objet (je vois les
sourires de mes interlocuteurs des threads pr=E9c=E9dents). J'ai d=E9velopp=
=E9
une petite appli de renommage de fichiers visible =E0 cette adresse :
et j'ai mis toute mon appli dans une m=EAme classe. Ce n'est peut-=EAtre
pas tr=E8s =E9l=E9gant.
Y-a-t-il une r=E8gle concernant l'architecture des programmes objet et
existe-t-il sur le web quelque chose qui en parle (si possible en
fran=E7ais) ? Je ne vois pas trop comment s=E9parer les diff=E9rentes
classes d'objet car tout est plus ou moins interd=E9pendant. Passant de
la programmation proc=E9durale =E0 la prog. objet je suis un peu perdu
pour organiser mon appli.
merci de vos conseils.
YLC
Si on rapproche ça du fait que la portabilité (applicative) passe souvent par un PPDC (Plus Petit Dénominateur Commun) des différentes plateformes, je pense que faire une application portable est synonyme d'une réduction fonctionnelle.
Dans le cas de Python, la lib standard dispose d'une couverture fonctionnelle plutôt large, la majorité des toolkits graphiques sont multiplateforme, donc se jeter sur des spécificités liées à une plateforme, au hasard les apis win32 natives, sans aucun discernement est loin d'être une idée fantastique.
Même MS semble trouver que ce n'est pas une idée vraiment terrible, par exemple .Net abstrait sévèrement les apis natives de Windows.
Et, pour moi, cela va à l'encontre des intérêts des utilisateurs pour lesquels on développe.
C'est vrai que les lier à une plateforme donnée (et à l'extrême avec une révision donnée d'icelle) pour qu'ils disposent du dernier gadget inutile de la dernière version en date d'un système ne va pas à l'encontre des dit-utilisateurs, du tout...
-- LL> je suis tres souvent sous linux, et je n'ai jamais eu besoin LL> de recompiler mon noyau. Toutafé. L'important avec les noyaux, c'est de ne pas les avaler. -+- SP in www.le-gnu.net - Pépin en bref : l'amer du palais -+-
Si on rapproche ça du fait que la portabilité (applicative) passe
souvent par un PPDC (Plus Petit Dénominateur Commun) des différentes
plateformes, je pense que faire une application portable est synonyme
d'une réduction fonctionnelle.
Dans le cas de Python, la lib standard dispose d'une couverture
fonctionnelle plutôt large, la majorité des toolkits graphiques sont
multiplateforme, donc se jeter sur des spécificités liées à une
plateforme, au hasard les apis win32 natives, sans aucun discernement
est loin d'être une idée fantastique.
Même MS semble trouver que ce n'est pas une idée vraiment terrible, par
exemple .Net abstrait sévèrement les apis natives de Windows.
Et, pour moi, cela va à l'encontre des intérêts des utilisateurs pour
lesquels on développe.
C'est vrai que les lier à une plateforme donnée (et à l'extrême avec une
révision donnée d'icelle) pour qu'ils disposent du dernier gadget
inutile de la dernière version en date d'un système ne va pas à
l'encontre des dit-utilisateurs, du tout...
--
LL> je suis tres souvent sous linux, et je n'ai jamais eu besoin
LL> de recompiler mon noyau.
Toutafé. L'important avec les noyaux, c'est de ne pas les avaler.
-+- SP in www.le-gnu.net - Pépin en bref : l'amer du palais -+-
Si on rapproche ça du fait que la portabilité (applicative) passe souvent par un PPDC (Plus Petit Dénominateur Commun) des différentes plateformes, je pense que faire une application portable est synonyme d'une réduction fonctionnelle.
Dans le cas de Python, la lib standard dispose d'une couverture fonctionnelle plutôt large, la majorité des toolkits graphiques sont multiplateforme, donc se jeter sur des spécificités liées à une plateforme, au hasard les apis win32 natives, sans aucun discernement est loin d'être une idée fantastique.
Même MS semble trouver que ce n'est pas une idée vraiment terrible, par exemple .Net abstrait sévèrement les apis natives de Windows.
Et, pour moi, cela va à l'encontre des intérêts des utilisateurs pour lesquels on développe.
C'est vrai que les lier à une plateforme donnée (et à l'extrême avec une révision donnée d'icelle) pour qu'ils disposent du dernier gadget inutile de la dernière version en date d'un système ne va pas à l'encontre des dit-utilisateurs, du tout...
-- LL> je suis tres souvent sous linux, et je n'ai jamais eu besoin LL> de recompiler mon noyau. Toutafé. L'important avec les noyaux, c'est de ne pas les avaler. -+- SP in www.le-gnu.net - Pépin en bref : l'amer du palais -+-
Michel Claveau - NoSpam SVP ; merci
Re !
Chouette, un peu de discussion...
Dans le cas de Python, la lib standard
La librairies standard : - comporte des modules spécifiques à certaines plateformes, et non "portables". Par exemple, entre autres, aetools, toute la série de carbon (Mac) ; cd ou gl (Irix) ; gdbm (unix) ; msvcrt (windows). - a des modules qui se comportent différemment selon les OS (pour quelques parties). Par exemple subprocess, glob, ctypes, et, même, os.path dans certains cas (noms de fichiers de plus de 255 caractères, par exemple).
Et, des différences, il y en a bien plus, dès que l'on sort du triplet Win/Mac/linux.
les lier à une plateforme donnée pour qu'ils disposent du dernier gadget inutile
En l'occurrence, je pense à un client, déjà équipé en ordinateurs, et où, dans une application de gestion, de nombreux documents sont générés dans OOo (ouverture de documents types, remplacements multiples, création de paragraphes, impression), qui est piloté, via COM, depuis une appli en Python. Cela ne fonctionne que sous windows. Alors, s'acharner sur une portabilité aurait enlevé aux utilisateurs cette fonctionnalité, qu'ils apprécient énormément.
Je rappelle que j'ai suggéré d'ignorer la portabilité, au niveau applicatif. Qu'elle reste un objectif au niveau du langage me semble, par contre, plus judicieux.
@-salutations -- Michel Claveau
Re !
Chouette, un peu de discussion...
Dans le cas de Python, la lib standard
La librairies standard :
- comporte des modules spécifiques à certaines plateformes, et non
"portables". Par exemple, entre autres, aetools, toute la série de
carbon (Mac) ; cd ou gl (Irix) ; gdbm (unix) ; msvcrt (windows).
- a des modules qui se comportent différemment selon les OS (pour
quelques parties). Par exemple subprocess, glob, ctypes, et, même,
os.path dans certains cas (noms de fichiers de plus de 255 caractères,
par exemple).
Et, des différences, il y en a bien plus, dès que l'on sort du triplet
Win/Mac/linux.
les lier à une plateforme donnée pour qu'ils disposent du dernier
gadget inutile
En l'occurrence, je pense à un client, déjà équipé en ordinateurs, et
où, dans une application de gestion, de nombreux documents sont générés
dans OOo (ouverture de documents types, remplacements multiples,
création de paragraphes, impression), qui est piloté, via COM, depuis
une appli en Python. Cela ne fonctionne que sous windows. Alors,
s'acharner sur une portabilité aurait enlevé aux utilisateurs cette
fonctionnalité, qu'ils apprécient énormément.
Je rappelle que j'ai suggéré d'ignorer la portabilité, au niveau
applicatif. Qu'elle reste un objectif au niveau du langage me semble,
par contre, plus judicieux.
La librairies standard : - comporte des modules spécifiques à certaines plateformes, et non "portables". Par exemple, entre autres, aetools, toute la série de carbon (Mac) ; cd ou gl (Irix) ; gdbm (unix) ; msvcrt (windows). - a des modules qui se comportent différemment selon les OS (pour quelques parties). Par exemple subprocess, glob, ctypes, et, même, os.path dans certains cas (noms de fichiers de plus de 255 caractères, par exemple).
Et, des différences, il y en a bien plus, dès que l'on sort du triplet Win/Mac/linux.
les lier à une plateforme donnée pour qu'ils disposent du dernier gadget inutile
En l'occurrence, je pense à un client, déjà équipé en ordinateurs, et où, dans une application de gestion, de nombreux documents sont générés dans OOo (ouverture de documents types, remplacements multiples, création de paragraphes, impression), qui est piloté, via COM, depuis une appli en Python. Cela ne fonctionne que sous windows. Alors, s'acharner sur une portabilité aurait enlevé aux utilisateurs cette fonctionnalité, qu'ils apprécient énormément.
Je rappelle que j'ai suggéré d'ignorer la portabilité, au niveau applicatif. Qu'elle reste un objectif au niveau du langage me semble, par contre, plus judicieux.
@-salutations -- Michel Claveau
Alex Marandon
Méta-MCI (MVP) wrote:
Aaaahhhh, la "portabilité". Un mot à la mode.
À la mode depuis bientôt 40 ans quand même. À l'échelle de l'histoire de l'informatique, ça semble être une mode qui dure ;-)
Mais, ce mot recouvre quoi ? Il traite de la portabilité d'un programme entre différentes plateformes. OK. Mais, de quelles plateformes parle-t'on ?
Ici, assez logiquement, on parle de celles sur lesquelles Python tourne.
En fait, j'ai remarqué que c'est essentiellement une demande faite par certains utilisateurs à propos de logiciels/programmes qui ne tournent pas sur leur plateforme favorite.
Des gens qui revendiquent seraient donc concernés par leur revendications ? Ça c'est un scoop !-)
Il n'est donc plus question d'universalité ou d'exo-intérêt, mais plutôt "je voudrais que ça tourne sur MA plateforme".
En tant que développeur, c'est plutôt "je voudrais que ça tourne sur votre plateforme".
Et, en pratique, il s'agit de Windows et de Linux. Avec, éventuellement, une tolérance pour MacOS.
Linux plus populaire que Mac OS ? Si seuleument c'était vrai (soupir)...
Méta-MCI (MVP) wrote:
Aaaahhhh, la "portabilité". Un mot à la mode.
À la mode depuis bientôt 40 ans quand même. À l'échelle de l'histoire de
l'informatique, ça semble être une mode qui dure ;-)
Mais, ce mot recouvre quoi ? Il traite de la portabilité d'un programme
entre différentes plateformes.
OK.
Mais, de quelles plateformes parle-t'on ?
Ici, assez logiquement, on parle de celles sur lesquelles Python tourne.
En fait, j'ai remarqué que c'est essentiellement une demande faite par
certains utilisateurs à propos de logiciels/programmes qui ne tournent
pas sur leur plateforme favorite.
Des gens qui revendiquent seraient donc concernés par leur
revendications ? Ça c'est un scoop !-)
Il n'est donc plus question d'universalité ou d'exo-intérêt, mais plutôt
"je voudrais que ça tourne sur MA plateforme".
En tant que développeur, c'est plutôt "je voudrais que ça tourne sur
votre plateforme".
Et, en pratique, il s'agit de Windows et de Linux. Avec,
éventuellement, une tolérance pour MacOS.
Linux plus populaire que Mac OS ? Si seuleument c'était vrai (soupir)...
À la mode depuis bientôt 40 ans quand même. À l'échelle de l'histoire de l'informatique, ça semble être une mode qui dure ;-)
Mais, ce mot recouvre quoi ? Il traite de la portabilité d'un programme entre différentes plateformes. OK. Mais, de quelles plateformes parle-t'on ?
Ici, assez logiquement, on parle de celles sur lesquelles Python tourne.
En fait, j'ai remarqué que c'est essentiellement une demande faite par certains utilisateurs à propos de logiciels/programmes qui ne tournent pas sur leur plateforme favorite.
Des gens qui revendiquent seraient donc concernés par leur revendications ? Ça c'est un scoop !-)
Il n'est donc plus question d'universalité ou d'exo-intérêt, mais plutôt "je voudrais que ça tourne sur MA plateforme".
En tant que développeur, c'est plutôt "je voudrais que ça tourne sur votre plateforme".
Et, en pratique, il s'agit de Windows et de Linux. Avec, éventuellement, une tolérance pour MacOS.
Linux plus populaire que Mac OS ? Si seuleument c'était vrai (soupir)...
Paul Gaborit
À (at) Sun, 4 Jan 2009 00:25:14 +0100, "Méta-MCI (MVP)" écrivait (wrote):
Aaaahhhh, la "portabilité". Un mot à la mode. Mais, ce mot recouvre quoi ? Il traite de la portabilité d'un programme entre différentes plateformes. OK. Mais, de quelles plateformes parle-t'on ?
En fait, j'ai remarqué que c'est essentiellement une demande faite par certains utilisateurs à propos de logiciels/programmes qui ne tournent pas sur leur plateforme favorite.
Il n'est donc plus question d'universalité ou d'exo-intérêt, mais plutôt "je voudrais que ça tourne sur MA plateforme".
Et, en pratique, il s'agit de Windows et de Linux. Avec, éventuellement, une tolérance pour MacOS. Quand aux autres plateformes, elles sont royalement ignorées.
Il faut bien voir que dans de nombreux cas, un portage Linux n'est pas loin d'un portage Unix et qu'avec Unix et Windows, on couvre quand même une majeure partie des plateformes utilisées.
Si on rapproche ça du fait que la portabilité (applicative) passe souvent par un PPDC (Plus Petit Dénominateur Commun) des différentes plateformes, je pense que faire une application portable est synonyme d'une réduction fonctionnelle. Et, pour moi, cela va à l'encontre des intérêts des utilisateurs pour lesquels on développe.
C'est une manière très réductrice de voir la portabilité.
La vrai portabilité, c'est d'utiliser (ou de développer) des bibliothèques proposant une API unique mais utilisant par dessous du code spécifique à chacune des plateformes.
Par exemple, le drag&drop des interfaces graphiques diffèrent entre Windows, MacOS X, Gnome, KDE et autres... Et pourtant, on trouve des bibliothèques permettant de l'utiliser sur toutes ces plateformes avec le même code appelant (évidemment l'implémentation est dépendante de la plateforme). L'exemple de la construction des chemins via os.path est un autre exemple de bonne bibliothèque de portabilité.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sun, 4 Jan 2009 00:25:14 +0100,
"Méta-MCI (MVP)" <enleverlesX.XmcX@XmclaveauX.com> écrivait (wrote):
Aaaahhhh, la "portabilité". Un mot à la mode.
Mais, ce mot recouvre quoi ? Il traite de la portabilité d'un
programme entre différentes plateformes.
OK.
Mais, de quelles plateformes parle-t'on ?
En fait, j'ai remarqué que c'est essentiellement une demande faite par
certains utilisateurs à propos de logiciels/programmes qui ne tournent
pas sur leur plateforme favorite.
Il n'est donc plus question d'universalité ou d'exo-intérêt, mais
plutôt "je voudrais que ça tourne sur MA plateforme".
Et, en pratique, il s'agit de Windows et de Linux. Avec,
éventuellement, une tolérance pour MacOS. Quand aux autres
plateformes, elles sont royalement ignorées.
Il faut bien voir que dans de nombreux cas, un portage Linux n'est pas
loin d'un portage Unix et qu'avec Unix et Windows, on couvre quand
même une majeure partie des plateformes utilisées.
Si on rapproche ça du fait que la portabilité (applicative) passe
souvent par un PPDC (Plus Petit Dénominateur Commun) des différentes
plateformes, je pense que faire une application portable est synonyme
d'une réduction fonctionnelle. Et, pour moi, cela va à l'encontre des
intérêts des utilisateurs pour lesquels on développe.
C'est une manière très réductrice de voir la portabilité.
La vrai portabilité, c'est d'utiliser (ou de développer) des
bibliothèques proposant une API unique mais utilisant par dessous du
code spécifique à chacune des plateformes.
Par exemple, le drag&drop des interfaces graphiques diffèrent entre
Windows, MacOS X, Gnome, KDE et autres... Et pourtant, on trouve des
bibliothèques permettant de l'utiliser sur toutes ces plateformes avec
le même code appelant (évidemment l'implémentation est dépendante de
la plateforme). L'exemple de la construction des chemins via os.path
est un autre exemple de bonne bibliothèque de portabilité.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sun, 4 Jan 2009 00:25:14 +0100, "Méta-MCI (MVP)" écrivait (wrote):
Aaaahhhh, la "portabilité". Un mot à la mode. Mais, ce mot recouvre quoi ? Il traite de la portabilité d'un programme entre différentes plateformes. OK. Mais, de quelles plateformes parle-t'on ?
En fait, j'ai remarqué que c'est essentiellement une demande faite par certains utilisateurs à propos de logiciels/programmes qui ne tournent pas sur leur plateforme favorite.
Il n'est donc plus question d'universalité ou d'exo-intérêt, mais plutôt "je voudrais que ça tourne sur MA plateforme".
Et, en pratique, il s'agit de Windows et de Linux. Avec, éventuellement, une tolérance pour MacOS. Quand aux autres plateformes, elles sont royalement ignorées.
Il faut bien voir que dans de nombreux cas, un portage Linux n'est pas loin d'un portage Unix et qu'avec Unix et Windows, on couvre quand même une majeure partie des plateformes utilisées.
Si on rapproche ça du fait que la portabilité (applicative) passe souvent par un PPDC (Plus Petit Dénominateur Commun) des différentes plateformes, je pense que faire une application portable est synonyme d'une réduction fonctionnelle. Et, pour moi, cela va à l'encontre des intérêts des utilisateurs pour lesquels on développe.
C'est une manière très réductrice de voir la portabilité.
La vrai portabilité, c'est d'utiliser (ou de développer) des bibliothèques proposant une API unique mais utilisant par dessous du code spécifique à chacune des plateformes.
Par exemple, le drag&drop des interfaces graphiques diffèrent entre Windows, MacOS X, Gnome, KDE et autres... Et pourtant, on trouve des bibliothèques permettant de l'utiliser sur toutes ces plateformes avec le même code appelant (évidemment l'implémentation est dépendante de la plateforme). L'exemple de la construction des chemins via os.path est un autre exemple de bonne bibliothèque de portabilité.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Eric Masson
"Michel Claveau - NoSpam SVP ; merci" writes:
'Lut,
La librairies standard : - comporte des modules spécifiques à certaines plateformes, et non "portables". Par exemple, entre autres, aetools, toute la série de carbon (Mac) ; cd ou gl (Irix) ; gdbm (unix) ; msvcrt (windows). - a des modules qui se comportent différemment selon les OS (pour quelques parties). Par exemple subprocess, glob, ctypes, et, même, os.path dans certains cas (noms de fichiers de plus de 255 caractères, par exemple).
Tu trouveras des contre exemples, mais comme pas mal de monde se tue à te le dire, l'important est d'utiliser des abstractions portables, les implémentations sur un système donné restent bien évidemment dépendantes de la plateforme cible.
Et, des différences, il y en a bien plus, dès que l'on sort du triplet Win/Mac/linux.
Non, c'est vrai ? C'est fou ce que tu peux être culturé comme garçon.
En l'occurrence, je pense à un client, déjà équipé en ordinateurs, et où, dans une application de gestion, de nombreux documents sont générés dans OOo (ouverture de documents types, remplacements multiples, création de paragraphes, impression), qui est piloté, via COM, depuis une appli en Python. Cela ne fonctionne que sous windows. Alors, s'acharner sur une portabilité aurait enlevé aux utilisateurs cette fonctionnalité, qu'ils apprécient énormément.
Ben, là dans un souci de portabilité, le boulot propre serait d'utiliser une abstraction de l'application cible à savoir Ooo, et d'enfouir la plomberie, à savoir COM, dans l'implémentation, ce qui permettrait de porter le code en ayant juste à implémenter la plomberie liée aux mécanismes IPC de la nouvelle plateforme cible.
Je rappelle que j'ai suggéré d'ignorer la portabilité, au niveau applicatif.
Et ce n'est toujours pas une bonne idée...
-- Discuter tranquillement avec Michel Guillou??? Je n'ai JAMAIS vu quelqu'un de plus *facho* que ce type. C'est écoeurant. -+- Rocou In GNU - T'as l'adresse des FFL, c'est pour écrire -+-
La librairies standard :
- comporte des modules spécifiques à certaines plateformes, et non
"portables". Par exemple, entre autres, aetools, toute la série de
carbon (Mac) ; cd ou gl (Irix) ; gdbm (unix) ; msvcrt (windows).
- a des modules qui se comportent différemment selon les OS (pour
quelques parties). Par exemple subprocess, glob, ctypes, et, même,
os.path dans certains cas (noms de fichiers de plus de 255 caractères,
par exemple).
Tu trouveras des contre exemples, mais comme pas mal de monde se tue à
te le dire, l'important est d'utiliser des abstractions portables, les
implémentations sur un système donné restent bien évidemment dépendantes
de la plateforme cible.
Et, des différences, il y en a bien plus, dès que l'on sort du triplet
Win/Mac/linux.
Non, c'est vrai ? C'est fou ce que tu peux être culturé comme garçon.
En l'occurrence, je pense à un client, déjà équipé en ordinateurs, et
où, dans une application de gestion, de nombreux documents sont générés
dans OOo (ouverture de documents types, remplacements multiples,
création de paragraphes, impression), qui est piloté, via COM, depuis
une appli en Python. Cela ne fonctionne que sous windows. Alors,
s'acharner sur une portabilité aurait enlevé aux utilisateurs cette
fonctionnalité, qu'ils apprécient énormément.
Ben, là dans un souci de portabilité, le boulot propre serait d'utiliser
une abstraction de l'application cible à savoir Ooo, et d'enfouir la
plomberie, à savoir COM, dans l'implémentation, ce qui permettrait de
porter le code en ayant juste à implémenter la plomberie liée aux
mécanismes IPC de la nouvelle plateforme cible.
Je rappelle que j'ai suggéré d'ignorer la portabilité, au niveau
applicatif.
Et ce n'est toujours pas une bonne idée...
--
Discuter tranquillement avec Michel Guillou???
Je n'ai JAMAIS vu quelqu'un de plus *facho* que ce type. C'est
écoeurant.
-+- Rocou In GNU - T'as l'adresse des FFL, c'est pour écrire -+-
La librairies standard : - comporte des modules spécifiques à certaines plateformes, et non "portables". Par exemple, entre autres, aetools, toute la série de carbon (Mac) ; cd ou gl (Irix) ; gdbm (unix) ; msvcrt (windows). - a des modules qui se comportent différemment selon les OS (pour quelques parties). Par exemple subprocess, glob, ctypes, et, même, os.path dans certains cas (noms de fichiers de plus de 255 caractères, par exemple).
Tu trouveras des contre exemples, mais comme pas mal de monde se tue à te le dire, l'important est d'utiliser des abstractions portables, les implémentations sur un système donné restent bien évidemment dépendantes de la plateforme cible.
Et, des différences, il y en a bien plus, dès que l'on sort du triplet Win/Mac/linux.
Non, c'est vrai ? C'est fou ce que tu peux être culturé comme garçon.
En l'occurrence, je pense à un client, déjà équipé en ordinateurs, et où, dans une application de gestion, de nombreux documents sont générés dans OOo (ouverture de documents types, remplacements multiples, création de paragraphes, impression), qui est piloté, via COM, depuis une appli en Python. Cela ne fonctionne que sous windows. Alors, s'acharner sur une portabilité aurait enlevé aux utilisateurs cette fonctionnalité, qu'ils apprécient énormément.
Ben, là dans un souci de portabilité, le boulot propre serait d'utiliser une abstraction de l'application cible à savoir Ooo, et d'enfouir la plomberie, à savoir COM, dans l'implémentation, ce qui permettrait de porter le code en ayant juste à implémenter la plomberie liée aux mécanismes IPC de la nouvelle plateforme cible.
Je rappelle que j'ai suggéré d'ignorer la portabilité, au niveau applicatif.
Et ce n'est toujours pas une bonne idée...
-- Discuter tranquillement avec Michel Guillou??? Je n'ai JAMAIS vu quelqu'un de plus *facho* que ce type. C'est écoeurant. -+- Rocou In GNU - T'as l'adresse des FFL, c'est pour écrire -+-
yveslc35
Eh les gars ! calmez-vous....on démarre seulement l'année. Et il faut rester zen sinon c'est mauvais pour les artères à ce qu'il parait !
Je ne pensais pas soulever un tel débat qui me dépasse un peu (et mêm e beaucoup d'ailleurs). J'ai quand même appris quelques petites choses. J'essayerai de faire mieux la prochaine fois. Bonne journée. YLC
Eh les gars ! calmez-vous....on démarre seulement l'année.
Et il faut rester zen sinon c'est mauvais pour les artères à ce qu'il
parait !
Je ne pensais pas soulever un tel débat qui me dépasse un peu (et mêm e
beaucoup d'ailleurs).
J'ai quand même appris quelques petites choses. J'essayerai de faire
mieux la prochaine fois.
Bonne journée.
YLC
Eh les gars ! calmez-vous....on démarre seulement l'année. Et il faut rester zen sinon c'est mauvais pour les artères à ce qu'il parait !
Je ne pensais pas soulever un tel débat qui me dépasse un peu (et mêm e beaucoup d'ailleurs). J'ai quand même appris quelques petites choses. J'essayerai de faire mieux la prochaine fois. Bonne journée. YLC
Méta-MCI \(MVP\)
Bonsoir !
Il faut bien voir ... qu'avec Unix et Windows, on couvre quand même une majeure partie des plateformes utilisées.
Je suis complètement d'accord. Mais, il est sous-entendu que quelqu'un qui développe sous ces deux OS, fait fi de la portabilité vers d'autre OS moins courants. La portabilité est donc toujours limitée, et c'est un choix que je comprends et défends.
par exemple, le drag&drop des interfaces graphiques diffèrent entre Windows, MacOS X, Gnome, KDE et autres... Et pourtant, on trouve des bibliothèques permettant de l'utiliser sur toutes ces plateformes avec le même code appelant
Contre-exemple : quelle bibliothèque permet de gérer à la fois les drag&drop que tu cites, et le drag&drop multipoint du iTouch/iPhone ? Dans ce cas, soit on joue la portabilité et on perd la fonctionnalité ; soit on joue la fonctionnalité au détriment de la portabilité. La portabilité reste un PPDC (Plus Petit Dénominateur Commun), qui laisse de côté bien des choses intéressantes.
@+ -- Michel Claveau
Bonsoir !
Il faut bien voir ... qu'avec Unix et Windows, on couvre quand même
une majeure partie des plateformes utilisées.
Je suis complètement d'accord.
Mais, il est sous-entendu que quelqu'un qui développe sous ces deux OS,
fait fi de la portabilité vers d'autre OS moins courants. La portabilité
est donc toujours limitée, et c'est un choix que je comprends et
défends.
par exemple, le drag&drop des interfaces graphiques diffèrent entre
Windows, MacOS X, Gnome, KDE et autres... Et pourtant, on trouve des
bibliothèques permettant de l'utiliser sur toutes ces plateformes avec
le même code appelant
Contre-exemple : quelle bibliothèque permet de gérer à la fois les
drag&drop que tu cites, et le drag&drop multipoint du iTouch/iPhone ?
Dans ce cas, soit on joue la portabilité et on perd la fonctionnalité ;
soit on joue la fonctionnalité au détriment de la portabilité.
La portabilité reste un PPDC (Plus Petit Dénominateur Commun), qui
laisse de côté bien des choses intéressantes.
Il faut bien voir ... qu'avec Unix et Windows, on couvre quand même une majeure partie des plateformes utilisées.
Je suis complètement d'accord. Mais, il est sous-entendu que quelqu'un qui développe sous ces deux OS, fait fi de la portabilité vers d'autre OS moins courants. La portabilité est donc toujours limitée, et c'est un choix que je comprends et défends.
par exemple, le drag&drop des interfaces graphiques diffèrent entre Windows, MacOS X, Gnome, KDE et autres... Et pourtant, on trouve des bibliothèques permettant de l'utiliser sur toutes ces plateformes avec le même code appelant
Contre-exemple : quelle bibliothèque permet de gérer à la fois les drag&drop que tu cites, et le drag&drop multipoint du iTouch/iPhone ? Dans ce cas, soit on joue la portabilité et on perd la fonctionnalité ; soit on joue la fonctionnalité au détriment de la portabilité. La portabilité reste un PPDC (Plus Petit Dénominateur Commun), qui laisse de côté bien des choses intéressantes.
@+ -- Michel Claveau
Paul Gaborit
À (at) Tue, 6 Jan 2009 23:52:20 +0100, "Méta-MCI (MVP)" écrivait (wrote):
Contre-exemple : quelle bibliothèque permet de gérer à la fois les drag&drop que tu cites, et le drag&drop multipoint du iTouch/iPhone ?
Quel intérêt puisque ce type de drag&drop est encore très peu répandu. Maintenant, rien n'empêche pour une bibliothèque portable de fournir la fonctionnalité avec, pour l'instant, un support limité à la seule plateforme iTouch/iPhone mais permettant son extension à d'autres plateformes lorsqu'elles le proposeront.
Reste à savoir que faire pour développer son application... Soit j'intègre du code drag&drop multipoint mais je dois prévoir un moyen de faire la même chose autrement pour les plateformes qui n'en disposent pas. Soit je m'interdis de l'utiliser et je retombe sur le plus petit dénominateur commun. Personnellement, j'adopte (quand je peux) la première possibilité.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 6 Jan 2009 23:52:20 +0100,
"Méta-MCI (MVP)" <enleverlesX.XmcX@XmclaveauX.com> écrivait (wrote):
Contre-exemple : quelle bibliothèque permet de gérer à la fois les
drag&drop que tu cites, et le drag&drop multipoint du iTouch/iPhone ?
Quel intérêt puisque ce type de drag&drop est encore très peu
répandu. Maintenant, rien n'empêche pour une bibliothèque portable de
fournir la fonctionnalité avec, pour l'instant, un support limité à la
seule plateforme iTouch/iPhone mais permettant son extension à
d'autres plateformes lorsqu'elles le proposeront.
Reste à savoir que faire pour développer son application... Soit
j'intègre du code drag&drop multipoint mais je dois prévoir un moyen
de faire la même chose autrement pour les plateformes qui n'en
disposent pas. Soit je m'interdis de l'utiliser et je retombe sur le
plus petit dénominateur commun. Personnellement, j'adopte (quand je
peux) la première possibilité.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Tue, 6 Jan 2009 23:52:20 +0100, "Méta-MCI (MVP)" écrivait (wrote):
Contre-exemple : quelle bibliothèque permet de gérer à la fois les drag&drop que tu cites, et le drag&drop multipoint du iTouch/iPhone ?
Quel intérêt puisque ce type de drag&drop est encore très peu répandu. Maintenant, rien n'empêche pour une bibliothèque portable de fournir la fonctionnalité avec, pour l'instant, un support limité à la seule plateforme iTouch/iPhone mais permettant son extension à d'autres plateformes lorsqu'elles le proposeront.
Reste à savoir que faire pour développer son application... Soit j'intègre du code drag&drop multipoint mais je dois prévoir un moyen de faire la même chose autrement pour les plateformes qui n'en disposent pas. Soit je m'interdis de l'utiliser et je retombe sur le plus petit dénominateur commun. Personnellement, j'adopte (quand je peux) la première possibilité.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
William Dode
On 06-01-2009, Méta-MCI (MVP) wrote:
...
La portabilité reste un PPDC (Plus Petit Dénominateur Commun), qui laisse de côté bien des choses intéressantes.
Le ppdc c'est aussi le kiss (garder les choses simples) et ce n'est pas forcément péjoratif !
Personnellement ça fait des années que mes clients ne demandent plus que ça : que ce soit simple.
-- William Dodé - http://flibuste.net Informaticien Indépendant
On 06-01-2009, Méta-MCI (MVP) wrote:
...
La portabilité reste un PPDC (Plus Petit Dénominateur Commun), qui
laisse de côté bien des choses intéressantes.
Le ppdc c'est aussi le kiss (garder les choses simples) et ce n'est pas
forcément péjoratif !
Personnellement ça fait des années que mes clients ne demandent plus que
ça : que ce soit simple.
--
William Dodé - http://flibuste.net
Informaticien Indépendant
