Microsoft / Monopole - Page 3

Kevin Kofler (./60) :
Ne trouves-tu pas un peu bizarre qu'il est le seul à défendre le format qui n'a pas d'adresse
@microsoft.com?

Forcément, si tu cherches des défendeurs d'un format MS sur slashdot ou linux.org, tu ne risques pas d'en trouver beaucoup...
Tu veux un blog dont l'auteur n'a pas d'adresse @microsoft.com ? http://blogs.developpeur.org/neodante/

Accessoirement, les liens pour l'ODF (enfin, surtout contre l'OpenXML ) sont soit de gens qui reprennent les arguments postés partout, soit des gens qui ont une adresse @ibm.com (ou équivalent...)

As-tu lu toutes les objections des autres personnes? Cf. mes liens, cf. aussi plein d'autres documents que Google peut certainement te ressortir.

Bin oui, et justement, tu y trouves des réponses dans le blog de Miguel de Icazas (notamment le SVG... il n'existe aucune implémentation complète du format, tellement il est dur... )

Peut-être que le format n'est pas parfait, mais il est quand même plus puissant que l'ODF, et donc mériterait plus que lui d'être choisi comme format unique

Flanker (./61) :
Bin oui, et justement, tu y trouves des réponses dans le blog de Miguel de Icazas

Déjà c'est "de Icaza", pas "de Icazas".
Et ensuite, il ne répond qu'à une petite partie des objections, avec des arguments pas très crédibles, genre que l'ODF expose aussi la structure interne de OO.o, alors que si tu lis les objections à l'O"O"XML, il y a plein d'endroits où l'ODF utilise des identifiants d'un standard ISO alors que O"O"XML utilise des entiers issus de l'API interne et non-standard Win32, et alors que l'ODF est également implémenté par d'autres applications comme KOffice (qui l'utilise comme son format par défaut!), il n'est pas du tout dépendant de la structure interne de OO.o contrairement à l'O"O"XML qui décrit 1:1 la structure interne de Office et du système d'exploitation sur lequel il tourne.
Et pour finir, si tu lis la fin, tu verras qu'il fait exprès de faire l'avocat du diable dans le but de secouer parce qu'il veut que l'ODF soit amélioré, en fait son but n'est pas vraiment de défendre le format (contrairement à ce pour quoi tu fais passer son texte).

(notamment le SVG... il n'existe aucune implémentation complète du format, tellement il est dur... )

Ce n'est pas une raison de ne pas prendre un sous-ensemble supporté du SVG. Le WMF est totalement propriétaire, et en plus ils utilisent 3 formats vectoriels différents (WMF + 2 formats décrits dans le standard). La consistence à l'intérieur du "standard" est aussi un gros point faible de ce soi-disant "standard".

Zephyr (./56) :
Sinon pour le fait de devoir aller regarder le code derrière, oui effectivement, mais on revient à une discussion qu'on avait eue à propos du passage par référence, qui ne se détecte pas au moment de l'appel d'une fonction, et oblige à aller voir son prototype (sauf en C# tiens, les passages par référence se voient ^^). C'est vrai, mais a priori en voyant "a + b", on est supposé savoir de quels types sont a et b, et donc on peut deviner sans trop de mal si le "+" a été redéfini ou non.

Mouais, enfin d'expérience le C++ m'a pas mal gavé parce que j'étais souvent obligé de bien connaître le code tiers que je voulais utiliser (pas seulement à cause de la surcharge des opérateurs, mais en partie quand même), et c'est ça qui m'a vraiment gavé (le coup des passages par référence qui ne se voient pas à l'appel par ex. heureusement que ce n'est plus le cas en C#, d'après ce que tu dis).

Sasume (./63) :

Zephyr (./56) :
Sinon pour le fait de devoir aller regarder le code derrière, oui effectivement, mais on revient à une discussion qu'on avait eue à propos du passage par référence, qui ne se détecte pas au moment de l'appel d'une fonction, et oblige à aller voir son prototype (sauf en C# tiens, les passages par référence se voient ^^). C'est vrai, mais a priori en voyant "a b", on est supposé savoir de quels types sont a et b, et donc on peut deviner sans trop de mal si le " " a été redéfini ou non.

Mouais, enfin d'expérience le C m'a pas mal gavé parce que j'étais souvent obligé de bien connaître le code tiers que je voulais utiliser (pas seulement à cause de la surcharge des opérateurs, mais en partie quand même), et c'est ça qui m'a vraiment gavé (le coup des passages par référence qui ne se voient pas à l'appel par ex. heureusement que ce n'est plus le cas en C#, d'après ce que tu dis).

Ouais, je suis d'accord, à reprendre après quelqu'un c'est strictement imbitable x_x. Au lieu d'aller directement voir le code qui pose problème, tu es obligé de te farcir toutes les surcharges d'opérateurs avant, de les avoir systématiquement ouvertes à côté pour être certain de ne pas te tromper... bref c'est vite insupportable. Ca revient (à mon sens) exactement au même que d'utiliser des noms non mnémoniques pour des méthodes ou des variables.

C'est marrant, je pensais pas que ça pouvait déranger à ce point (ça m'intéresse, pour un vapor qui fume depuis longtemps); donc pour vous il serait une meilleure solution d'interdire complètement la redéfinition des opérateurs ?

Sasume > Pour passer une variable par référence en C#, on doit utiliser le mot clé "ref", ce qui donne "a.func (ref b)" au lieu de "a.func (b)" pour un passage normal. Du coup oui, ça se voit, mais je ne trouve pas spécialement élégant ^^

Zephyr (./65) :
C'est marrant, je pensais pas que ça pouvait déranger à ce point (ça m'intéresse, pour un vapor qui fume depuis longtemps); donc pour vous il serait une meilleure solution d'interdire complètement la redéfinition des opérateurs ?

Ben je conçois que ça puisse avoir son utilité dans certains cas, en particulier quand on développe seul, ou un produit "one shot". Par contre, dès qu'on doit faire du travail d'équipe sur un produit qui va devoir évoluer sur plusieurs années (avec plusieurs équipes qui vont se succéder), je trouve ça particulièrement lourd à maintenir.

Je ne vois pas trop pourquoi ça ne pourrait pas être utilisé si c'est bien fait. par exemple je travaille avec un moteur 3D et les opérations arithmétiques (+-*) sur des matrices, vecteurs et quaternions passent par des opérateurs surchargés et c'est très propre et très clair

C'est le "si c'est bien fait" qui est tout relatif en fait, sinon je suis d'accord avec toi dans la théorie.

Le passage par référence qui "se voit", ça existe en C++ aussi, et même en C, ça s'appelle le passage par pointeur.

Oui, sauf que C++ a introduit la notation "type& var", ne fais pas comme si tu ne le savais pas. Et c'est là-dessus que crachait Zephyr je pense.
Et sur les pointeurs, je crois qu'on peut relever un défaut assez pénible : c'est très bas niveau, ça permet de faire des conneries, ça peut donner lieu à des plantages violents, etc.

Kevin Kofler (./62) :

Flanker (./61) :
Bin oui, et justement, tu y trouves des réponses dans le blog de Miguel de Icazas

Déjà c'est "de Icaza", pas "de Icazas".Et ensuite, il ne répond qu'à une petite partie des objections, avec des arguments pas très crédibles, genre que l'ODF expose aussi la structure interne de OO.o, alors que si tu lis les objections à l'O"O"XML, il y a plein d'endroits où l'ODF utilise des identifiants d'un standard ISO alors que O"O"XML utilise des entiers issus de l'API interne et non-standard Win32, et alors que l'ODF est également implémenté par d'autres applications comme KOffice (qui l'utilise comme son format par défaut!), il n'est pas du tout dépendant de la structure interne de OO.o contrairement à l'O"O"XML qui décrit 1:1 la structure interne de Office et du système d'exploitation sur lequel il tourne.

ODF est le format d'OO, à peine modifié, tout comme OpenXML est le format d'Office, à peine modifié...

Et pour finir, si tu lis la fin, tu verras qu'il fait exprès de faire l'avocat du diable dans le but de secouer parce qu'il veut que l'ODF soit amélioré, en fait son but n'est pas vraiment de défendre le format (contrairement à ce pour quoi tu fais passer son texte).

Donc finalement, s'il dit du bien d'ODF, on peut l'écouter, s'il en dit du mal, il faut le discréditer ?
Et quelle que soit sa position, ses arguments sont toujours valables...

(notamment le SVG... il n'existe aucune implémentation complète du format, tellement il est dur... )

Ce n'est pas une raison de ne pas prendre un sous-ensemble supporté du SVG. [/cite]
Sauf qu'aucun sous-ensemble du SVG n'est précisé !


Bizarrement, aucun argument pour l'ODF, à part qu'il est « libre » ()
L'OpenXML est plus puissant, mieux documenté donc mériterait d'être normalisé... Je ne dis pas qu'il est parfait, mais justement, le processus de normalisation est là pour corriger ses quelques défauts

Kevin Kofler (./52) :
Et sinon, un grand problème de Office "Open" XML est qu'il est breveté aux USA! Oui, un soi-disant "format ouvert" breveté.

Mais on s'en fout qu'il soit breveté... Tu as l'assurance de pouvoir l'utiliser comme tu veux complètement gratuitement... Contrairement au PDF, par exemple

moi je pense comme l'afnor. Faut merger les deux formats et on arrête de se prendre le chou.

Et tu fais comment s'ils sont fondamentalement différents ?

tu fais comme opentype avec truetype et type1, tu fais un gros wrapper qui peut contenir un fichier dans l'un ou l'autre format (le format opentype c'est vraiment ça hein ^^)

Flanker (./71) :
L'OpenXML est plus puissant

Justement non. http://www.grokdoc.net/index.php/EOOXML_objections#Alternate.2C_standards-based_resolution
Regarde par exemple les hacks autoSpaceLikeWord95 et useWord97LineBreakRules que ODF gère de manière beaucoup plus flexible que juste "faire comme le vieux Word" ou "faire comme le dernier Word".

mieux documenté

Mais on s'en fout qu'il soit breveté... Tu as l'assurance de pouvoir l'utiliser comme tu veux complètement gratuitement...

Bah non.
http://www.grokdoc.net/index.php/EOOXML_objections#Patent_rights_to_implement_the_Ecma_376_specification_have_not_been_granted
http://www.noooxml.org/patents

Je ne vois pas pourquoi tu te permets d'argumenter alors que tu n'as même pas survolé les liens que je t'ai donnés. Je ne vais quand-même pas copier-coller tout ce qu'ils écrivent!

de toute façon l'OOXML s'est fait jeter de l'ISO.

C'est pas parce que l'ISO ne reconnaît pas un format comme un standard qu'il ne va pas devenir un monopole ^^

squalyl (./76) :
de toute façon l'OOXML s'est fait jeter de l'ISO.

Malheureusement juste pour ce tour de vote, ils vont revoter en Février.

on sait pas si microsoft aura le temps de faire toutes les modifs demandées

Kevin Kofler (./62) :
alors que l'ODF est également implémenté par d'autres applications comme KOffice

Implémenté… seulement partiellement…
http://testsuite.opendocumentfellowship.org/

Kevin Kofler (./75) :

Flanker (./71) :
L'OpenXML est plus puissant

Justement non. http://www.grokdoc.net/index.php/EOOXML_objections#Alternate.2C_standards-based_resolution
Regarde par exemple les hacks autoSpaceLikeWord95 et useWord97LineBreakRules que ODF gère de manière beaucoup plus flexible que juste "faire comme le vieux Word" ou "faire comme le dernier Word".

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…

Qu'en est-il de l'accessibilité, des règles pour les créations de formules dans les tableurs (et oui, pour l'instant, une formule mathématique est définie comme une chaîne, tu peux écrire n'importe quoi et c'est considéré comme valide en ODF ), des métadonnées, les tables de façon native dans les présentations (et non sous la forme d'un tableur importé), … ?

mieux documenté

Et naturellement, tu as pris la peine de te documenter ?
Parce que quand tu regardes ODF et OpenOffice…
Les balises PageViewZoomValue, AutoCalculate, AddParaSpacingToTableCells, PrintPageBackground, ZoomFactor, ZoomType, ZoomValue (il y en a des dizaines !) sont dites « Application defined » et leur comportement n'est pas décrit. Chaque suite l'implémente comme elle veut... Super pratique pour l'interopérabilité, tu ne trouves pas ?
Dans OpenXML, aucune balise n'est définie comme étant « Application Defined ». Seules certaines balises optionnelles et de compatibilité n'étaient que partiellement documentées (je crois que ça a changé depuis)
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).

Mais on s'en fout qu'il soit breveté… Tu as l'assurance de pouvoir l'utiliser comme tu veux complètement gratuitement…

Bah non.
http://www.grokdoc.net/index.php/EOOXML_objections#Patent_rights_to_implement_the_Ecma_376_specification_have_not_been_granted
http://www.noooxml.org/patents

Je ne vois pas pourquoi tu te permets d'argumenter alors que tu n'as même pas survolé les liens que je t'ai donnés. Je ne vais quand-même pas copier-coller tout ce qu'ils écrivent!

Faut dire qu'ils sont tellement objectifs

Zephyr (./65) :
pour vous il serait une meilleure solution d'interdire complètement la redéfinition des opérateurs ?

oui. Comme pour concaténer des string c'est super pratique, et que tout le monde doit utiliser des string, je laisserais quand même la surcharge du "+" pour les strings.

Kevin Kofler (./69) :
Le passage par référence qui "se voit", ça existe en C++ aussi, et même en C, ça s'appelle le passage par pointeur.

On se moque que ça "existe" en C++. De toute façon il y a presque tout qui existe en C++. Le problème c'est que "type& var" existe.

Bah nan, un string etant pas un type natif, on doit alors retirer ca.

Sinon, ouais c'est dangereux les surcharges, et pas mal de companies interdisent d'utiliser ca dans leurs codes C++, pke c'est simplemenet la merde qunad le dev. fait dans le zele.
M'enfin, pour les projets perso, ou petite taille... c quand meme tres pratique. Rien qu'un flux, c'est genial quand meme!

Flanker (./80) :

Mais on s'en fout qu'il soit breveté… Tu as l'assurance de pouvoir l'utiliser comme tu veux complètement gratuitement…

Bah non.
http://www.grokdoc.net/index.php/EOOXML_objections#Patent_rights_to_implement_the_Ecma_376_specification_have_not_been_granted
http://www.noooxml.org/patents

Je ne vois pas pourquoi tu te permets d'argumenter alors que tu n'as même pas survolé les liens que je t'ai donnés. Je ne vais quand-même pas copier-coller tout ce qu'ils écrivent!

Faut dire qu'ils sont tellement objectifs

Suffit de voir le nom de domaine du second, ça prouve l'objectivité !

Comme pour concaténer des string c'est super pratique, et que tout le monde doit utiliser des string, je laisserais quand même la surcharge du "+" pour les strings

C'est marrant de vous lire quand on n'y connait rien

nEUrOO (./82) :
Bah nan, un string etant pas un type natif, on doit alors retirer ca.

ça doit se faire par méthodes.

oui remarque, c'est vrai que concat("abc",str1,3) c'est pas plus mal

Ou alors il faut avoir une définition des strings comme étant un type natif, mais ça va à l'encontre de l'esprit objet.

La surcharge d'opérateur est... comment dire... la cerise sur le gateau du C++. C'est trop bon.

J'utilisais une libriairie de résolution de programme linéaire. Ils ont TOUT surchargé (pas que les opérateurs, mais je vais y venir) les variables de décision par exemple, c'est les variables que le solveur va résoudre, on dérive de leur classe pour ajouter des membres si on veut.. la beauté de la prog OO quoi.

Maintenant pour définir une expression linéaire, vu qu'ils ont surchargé les opérateurs, on peut écrire un truc du genre:

IloNumExpr expr = x[0] + 2*x[1] + 3*x[2]

et en java, on doit écrire:

IloNumExpr expr = cplex.sum(x[0], cplex.prod(2.0, x[1]),cplex.prod(3.0, x[2]));
C'est vrai qu'on sait pas du tout ce qui se passe derrière quand on écrit x+y.. Mais j'ai une petite idée, ca doit le considérer comme une addition. Tout comme je me douterais que cplex.sum fait une addition, mais on doit de toute façon lire les spéc. avant d'utiliser une classe.

Dites moi en quel autre langage on peut faire des choses aussi belles? En .NET aussi, on peut écrire aussi joliment qu'en C++, parce que surcharge des opérateurs

En CAML on fait des choses encore plus belles

Jyaif (./81) :
oui. Comme pour concaténer des string c'est super pratique, et que tout le monde doit utiliser des string, je laisserais quand même la surcharge du "+" pour les strings.

Alors ça par contre non, c'est un cas particulier, et j'aime pas les cas particuliers