Microsoft / Monopole - Page 6

ExtendeD (./150) :
Avec l'auto-boxing de Java 5 plus de problèmes (à part pour les passages par référence comme tu notes).

Ça consiste en quoi l'auto-boxing ? (si ça peut s'expliquer en 3 mots, sinon ne te casse pas la tête j'irai chercher sur google)

Java 5 a ses boucles améliorées. instanceof est l'équivalent de is, mais il n'y a pas de as (est-ce vraiment utile ?)

Boucles améliorées ? Pour l'instant, il me manquait en Java la possibilité de pouvoir parcourir rapidement une collection ("foreach (Type item in list) item.method ()" en C#), ou encore appliquer un traitement à tous les éléments d'une collection (en appelant une méthode de la collection qui prend en paramètre les instructions à effectuer). Sinon le "as" est plus utile que le is : le as est l'équivalent du dynamic_cast<> du C++, qui permet donc de vérifier la validité d'un cast et de l'effectuer le cas échéant, tandis que le is n'est qu'une sorte de "if (var as Type != null)".

Tout ça est pris en charge directement par Groovy, lorsque l'on souhaite troquer Java pour des facilités syntaxiques. Groovy n'est pas une bizarrerie, il deviendra très probablement prochainement un langage standard alternatif (il est déjà standardisé), et au moins un des pilier techniques. Il propose une compatibilité complète et bidirectionnel avec Java (le "vrai"). Je code au moins 1.5 fois plus vite avec et en 2 fois moins de place.

Bookmarké, j'irai voir ça

[edit] er => é

En java le foreach n'est pas très explicite (quand on lit le code) :[code]for(item : collection) { ... }[/code]

Zephyr (./151) :
il me manquait en Java la possibilité de pouvoir parcourir rapidement une collection

cf ça (Sasume : c'est bon, ça pourrait être pire... Groovy propose for (e in list) comme syntaxe).

Ou encore appliquer un traitement à tous les éléments d'une collection (en appelant une méthode de la collection qui prend en paramètre les instructions à effectuer).

Tout le monde est en train de pinailler sur la future implémentation des closures dans Java 7, c'est pitoyable, y'a tellement de choses plus importantes... Groovy propose ça en attendant, c'est bien pratique

Zephyr (./151) :
Sinon le "as" est plus utile que le is : le as est l'équivalent du dynamic_cast du C , qui permet donc de vérifier la validiter d'un cast et de l'effectuer le cas échéant

Mais j'ai du mal à voir l'utilisation, tu fais bien aussi un test != null à la fin d'un "as" de toute façon, non ?

Kevin Kofler (./108) :

Tu te fous de moi ? Là tu parles d'options qui n'existent que pour la compatibilité, et qui ne doivent pas être utilisées pour créer de nouveaux documents…

Mais l'ODF propose de vraies options qui gèrent non seulement les cas "oui" et "non" de ces hacks de compatibilité, mais aussi tous les autres réglages possibles (alors que "Open" XML code un réglage en dur et permet de choisir un autre réglage codé en dur avec le hack de compatibilité).

Mais on s'en fout, c'est pour la compatibilité... comme ça ne doit pas être utilisé pour de nouveaux documents, pas besoin de les gérer de souple ou pas...

Qu'en est-il de l'accessibilité

L'accessibilité, n'est-ce pas un problème de l'application, pas des documents?

Bah non, la preuve, ODF va être modifié pour la prendre en compte ^^
(et il y a déjà un semblant d'accessibilité dans HTML et CSS, les indications pour les périphs pour les aveugles, par exemple)

Dans OpenXML, aucune balise n'est définie comme étant « Application Defined ».

C'est vrai, à la place ce n'est pas défini du tout.

si elles ne sont pas définies dans le format, elles n'existent pas

Quant aux "application-defined" de ODF, c'est parce que l'ODF définit le contenu du document, pas l'affichage qui est un problème de l'application. Or ZoomFactor est un problème d'affichage. C'est stocké dans le document pour qu'une application puisse s'en rappeler entre enregistrements (c'est ça la raison pour laquelle ces tags application-defined existent!), mais il est évident qu'un zoom de 150% n'aura pas le même rendu sur une TI-89 que sur un écran 29". Mais ce n'est pas grave, le facteur zoom, chacun peut le régler comme il veut dans les menus sans changer le contenu du document!

et AddParaSpacingToTableCells ?
(puis quel intérêt d'avoir un wysiwyg si c'est pour ne pas avoir le même rendu sur toutes les applis ? )

Sinon, tu peux regarder également du côté des énumérations (1,2,3, …) que tu peux très bien écrire avec plein de systèmes de numérations différents avec Office (en toutes lettres, en chiffres romains, japonais, chinois, …). Tout est clairement défini pour OXML, alors que pour ODF, non seulement le choix est beaucoup plus restreint, mais c'est ambigu (ODF utilise seulement les 3 premiers nombres pour définir la numérotation, et ce n'est pas toujours suffisant).

Ah bon? Tu proposes de compter comment? 1, 2, 3, 5, 8, 13, 21, ...?
Énumérer les 3 premiers nombres, ça permet d'utiliser les caractères numéraux Unicode plutôt que des IDs codés en dur (de type 1=arabe, 2=romain, ...).

Certaines énumérations se différencient à partir de 10 (dans différents pays d'Asie du Sud-Est, il me semble)

Kevin Kofler (./137) :

Pollux (./133) :
maintenant à toi de me trouver un problème dans le format word97 qui 1] nécessiterait un changement significatif du format, pas une simple extension, et 2] ne serait pas du bloat inadapté à l'usage que les gens font d'un traitement de texte)

Le problème, c'est que le format n'est pas le standard ISO, qui est l'ODF!
Mais bien sûr le monopole a préféré redéfinir l'obscurité^H^H^H^H^H^H^H^H^H^H^Hl'Office "Open" XML (qui n'est qu'un mapping XML du vieux format binaire avec toutes ses bizarreries, c'est pour ça que c'est aussi lié aux applications et au système d'exploitation qui l'implémentent et qu'il y a tellement de constantes numériques en le format non-standard de ce système d'exploitation monopoliste là où ils devraient utiliser des identifiants alphanumériques ISO) comme le nouveau standard au lieu de changer l'ampoule^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hpasser à l'ODF.

L'argument de la compatibilité est le plus souvent ramené quand on parle de l'intérêt des formats ouverts, et là tu proposes de faire une croix sur tous les documents précédents ? #zygus#


Là, je vois qu'il y a un format ODF qui n'est vraiment pas assez puissant (pas d'accessibilité, etc.), pas du tout répandu, avec plusieurs révisions qui arrivent alors qu'il n'est pas toujours complètement implémenté, et un format OpenXML avec seulement quelques problèmes qui peuvent être bien plus facilement résolus, compatible avec 99% des documents déjà écrits
Je ne vois vraiment pas pourquoi il ne faudrait pas chercher à corriger les défauts d'OpenXML plutôt que l'enterrer

Flan: oui mais tu comprend, l'OpenXML est fait par Microsoft, donc forcement, meme si c'est bien, c'est mal.

./154: Heu là, ton lancer était un poil trop visible. Tout le monde va s'en rendre compte.

Flanker (./154) :

Kevin Kofler (./108) :

Tu te fous de moi ? Là tu parles d'options qui n'existent que pour la compatibilité, et qui ne doivent pas être utilisées pour créer de nouveaux documents…

Mais l'ODF propose de vraies options qui gèrent non seulement les cas "oui" et "non" de ces hacks de compatibilité, mais aussi tous les autres réglages possibles (alors que "Open" XML code un réglage en dur et permet de choisir un autre réglage codé en dur avec le hack de compatibilité).

Mais on s'en fout, c'est pour la compatibilité... comme ça ne doit pas être utilisé pour de nouveaux documents, pas besoin de les gérer de souple ou pas...

Justement, qui dit que ça ne doit pas être utilisé pour de nouveaux documents? Pour toi, tous les documents du monde et tous les traîtements de textes du monde devraient-ils utiliser les mêmes métriques que Word 2003? C'est bien là le problème de l'"Open" XML, il impose des métriques codées en dur, alors que ODF permet de mettre n'importe quelle constante. Si un ancien Word utilisait une autre valeur pour la constante, c'est bien qu'il y a plusieurs valeurs raisonnables! Et un autre traîtement de texte pourrait utiliser encore une autre valeur par défaut que les deux versions de Word. Donc c'est l'ODF le format le plus souple, pas l'"Open" XML!

Bah non, la preuve, ODF va être modifié pour prendre en compte [l'accessibilité] ^^

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office-accessibility
s/va être/a été/
Ça a déjà été intégré à la version 1.1!

De plus, il y a aussi des accessibility guidelines: http://www.oasis-open.org/committees/download.php/20977/ODF_Accessibility_Guidelines_14_2Nov06.odt.

si elles ne sont pas définies dans le format, elles n'existent pas

Bah si, Office met des trucs dans les documents qui ne sont pas documentés dans le "standard". Dans l'ODF, tout ce que OpenOffice.org met dans les documents est mentionné dans la spécification, c'est pour ça qu'ils ont besoin de quelques éléments réservés.

et AddParaSpacingToTableCells ?

C'est documenté, ça: http://api.openoffice.org/docs/common/ref/com/sun/star/text/DocumentSettings.html
Maintenant, pourquoi ce n'est pas spécifié à l'intérieur du standard, je ne sais pas. Mais quelqu'un qui veut être intéropérable avec OpenOffice.org a la documentation qu'il lui faut, ce qui n'est pas le cas des options DooFooLikeBar31337 de l'Office "Open" XML.

(puis quel intérêt d'avoir un wysiwyg si c'est pour ne pas avoir le même rendu sur toutes les applis ? )

Changer le facteur de zoom n'est pas un changement de rendu.

L'argument de la compatibilité est le plus souvent ramené quand on parle de l'intérêt des formats ouverts, et là tu proposes de faire une croix sur tous les documents précédents ? #zygus#

Non, de les convertir en ODF. KOffice a bien réussi à faire ça avec leur format de documents, pourquoi pas Office? Et OpenOffice.org peut bien convertir les formats binaries Office en ODF!

Et la compatibilité, ce n'est pas seulement la compatibilité antérieure avec les formats fermés précédents, mais aussi l'interopérabilité avec les autres suites bureautiques! C'est bien ça l'intérêt du standard, et OpenOffice.org et KOffice montrent que c'est possible.

Là, je vois qu'il y a un format ODF qui n'est vraiment pas assez puissant (pas d'accessibilité, etc.),

Cf. ci-dessus, les modifications pour l'accessibilité ont déjà été effectuées dans l'ODF 1.1.

pas du tout répandu,

L'ODF est géré par pratiquement toutes les suites bureautiques, avec comme seule exception le quasi-monopole anti-compétitif dont il est question dans ce topic. Et c'est bien ça le problème: ils profitent de leur domination du marché pour appeler tout ce qui ne vient pas d'eux "pas du tout répandu" comme tu viens de le faire (c'est-à-dire que tu es tombé en plein dans le panneau).

avec plusieurs révisions qui arrivent

Ben, eux ils tiennent compte des remarques qu'on leur fait! Et les révisions sont compatibles, alors que pas mal des problèmes de l'Office "Open" XML sont des problèmes de conception fondamentaux qui ne peuvent pas être corrigés sans casser la compatibilité (et donc autant passer au standard établi: l'ODF!).

alors qu'il n'est pas toujours complètement implémenté,

L'Office "Open" XML non plus! Il y a une différence entre ce que Office génère actuellement et le document qu'ils essaient de standardiser. Et en plus je suis sûr que les versions futures de Office resteront compatibles avec la version actuelle même si ça contredit le standard, étant donné l'importance relative donnée par cette entreprise à la compatibilité antérieure par rapport à l'interopérabilité.

et un format OpenXML avec seulement quelques problèmes qui peuvent être bien plus facilement résolus,

Absolument pas. Les objections les plus importantes nécessitent une reconception du format entier. Par exemple le fait que l'"Open" XML n'utilise pas les tags inline, genre:
foo <tag>bar</tag> baz
mais une représentation complexe de type:
<texte>foo</texte><tag/><texte>bar</texte><antitag/><texte>baz</texte>
illisible. Ou le fait que des représentations de dates, pays etc. du système d'exploitation sont utilisées plutôt que celles de l'ISO. Ou le fait que les formats vectoriels utilisés sont non standard. Etc.

compatible avec 99% des documents déjà écrits

L'ODF aussi.

Je ne vois vraiment pas pourquoi il ne faudrait pas chercher à corriger les défauts d'OpenXML plutôt que l'enterrer

Corriger les défauts == remplacer par l'ODF (étant donné que le défaut numéro 1 est le fait que ce n'est pas le standard ISO existant, et étant donné aussi les autres défauts fondamentaux qui nécessiteraient une reconception complète).

ExtendeD (./153) :
cf ça (Sasume : c'est bon, ça pourrait être pire... Groovy propose for (e in list) comme syntaxe).

Comme disait Sasume c'est pas spécialement beau mais ça fait la même chose, donc ok

Mais j'ai du mal à voir l'utilisation, tu fais bien aussi un test != null à la fin d'un "as" de toute façon, non ?

Oui mais justement, le as a deux emplois; tu peux t'en servir pour tester l'appartenance d'un objet à une hiérarchie de classe (c'est ce que permet "is"), ou pour réaliser le cast en lui-même. Bien souvent, tu peux avoir à faire les deux à la suite, dans le style "if ((a as Type) != null) (a as Type).method ();". Alors certes, dans ce cas on peut remplacer la deuxième ligne par un cast classique, mais le "as" devient plus intéressant quand on passe "a as Type" en paramètre à une fonction par exemple, à qui tu déchargeras la responsabilité de vérifier que la valeur n'est pas nulle (tandis qu'avec un cast elle aurait reçu une valeur toujours non nulle et potentiellement invalide). En comparaison, le "is" n'est pas indispensable.

Quoiqu'il en soit je me fais l'avocat du diable, puisque les dynamic casts, c'est maaaal

qobject_cast rulez.

bah... non, c'est tout autant de la merde, c'est pas parceque ça s'écrit pas pareil que ça change quelque chose

Bref, vive le typage dynamique (un camarade troll pour les autres qui trainent déjà ici)

oué, ((Type)var).truc() ça vous suffit pas?

(c'est pas ça le typage dynamique ^^)

(et c'est moins joli à lire)

C'est
i = 1 ;
s = "BONJOUR" ;
i++ ;
i = i + s ;
Et tout ça, ça marche
(ou alors on ne parle pas du tout de la même chose ?)
edit : ah merde oué j'avais pas vu qu'on parlait objets)

ah d'accord.

en fait je sais pas a quoi sert dynamic_cast toussa

sinon, groovy ça a l'air marrant

Est-ce qu'il existe une implémentation potable, non Microsoftienne, de OOXML ?

Pourquoi ? tu hésites à en faire une ?

oui il est motivé !

dualmoo (./167) :
Est-ce qu'il existe une implémentation potable, non Microsoftienne, de OOXML ?

J'en sais rien, mais en tout cas il existe au moins une implémentation (celle de MS, justement )
Et celle d'OpenOffice est pas mal avancée, je crois

Celle que Novell fait dans son coin pour OO.o plutôt. Cette implémentation ne sera probablement pas distribuée par grand monde à part Novell à cause des problèmes évidents de brevets logiciels!

pourquoi problèmes ? c'est une solution à la base le brevet logiciel...
pourquoi évidents ? il n'y a rien de flagrant, à moins que Nov€ll te soit aussi antipathique que Micro$oft

vince (./172) :
pourquoi évidents ? il n'y a rien de flagrant, à moins que Nov€ll te soit aussi antipathique que Micro$oft

Évidemment, ils ont signé un pacte avec le Diable


(mais ça m'étonnerait que ça ne soit pas distribué... vu la politique d'Ubuntu, ça m'étonnerait qu'ils n'intègrent pas ce genre de patch )

vince (./172) :
pourquoi problèmes ? c'est une solution à la base le brevet logiciel...

Déjà je ne suis pas d'accord, et tu trouveras plein de sites en ligne qui t'expliquent pourquoi les brevets logiciels, c'est mal.

Et ensuite, ici, le problème est que l'entreprise qui a un brevet logiciel là-dessus (et je rappelle que ce n'est pas Novell, mais leurs nouveaux "partenaires"!) n'a fourni aucune licence d'utilisation pour ce brevet, et encore moins une licence compatible avec une implémentation sous GPL.

Si openoffice supporte entièrement, dans un futur proche, OOXML, je reverrai pas mal ma position à ce sujet. Mais pour l'instant j'ai clairement l'impression d'un standard non implémentable par qui que ce soit (ce qui sert par ailleurs les intérêts de MS : si une suite office sait écrire du word et est gratuite, je vois mal ce qui poussera le péquin moyen à continuer d'acheter office à chais pas combien de centaines de dollars). C'est pour ça que j'ai du mal à y croire. Tant mieux si je me trompe.

./174 > oui mais ça c'est pas grave, il suffit de décider une bonne fois pour toutes que les brevets logiciels sont illégaux, et pas besoin de licence ^^

Va dire ça aux USA...
Les logiciels illégaux aux USA posent plein de problèmes, par exemple beaucoup de distributions GNU/Linux ne peuvent pas (car basées aux USA) ou ne veulent pas (pour pouvoir vendre aux USA) les distribuer.

(vous avez vu ? Il semblerait qu'IBM va contribuer à Open Office (article vu dans yNews cet aprem))

ça ne m'étonne pas plus que ça, vu la pression qu'ils mettent pour qu'OpenXML soit rejeté...

Bha avec un peu de chance, connaissant IBM, OpenOffice serait utilisable apres...