LupusMic a écrit 1481 commentaires

L'erreur c'est d'utiliser Eclipse →[]

En fait, il manque plein de morceau dans ton appel à contribution. Est-ce que tu as la main sur les proxies ? Est-ce que ce sont des miroirs ?

Si je comprends bien ton problème, l'indexation de DLFP dans les moteurs de recherche est pourrie par des miroirs sauvages de DLFP, et tu voudrais donc neutraliser l'effet de ces sites ?

Selon le proxy, la réponse ne sera pas la même.

D'autres découvertes fracassantes du même genre:

• le mois de juillet a 31 jours

Certes.

• l'eau mouille

Ça dépend.

• péter pue

À prouver avec une étude.

Donc, vas-y, donne nous ta version de code qui fait la même chose en respectant la fameuse loi.

Le soucis est que tu veux faire quelque chose d'aberrant (contrôler le rendu graphique depuis n'importe quel point de l'application). Ça posera beaucoup de problèmes d'interdépendance des différentes parties du code, si tu fais ça.

Trolleur :)

Certes, mais je ne parviens toujours pas à comprendre l'intérêt de l'introspection.

Euh, pouvoir se balader avec un pointeur, c'est pouvoir défoncer n'importe quelle tentative d'encapsulation.

Sauf qu'il faut vraiment en vouloir pour défoncer l'encapsulation. À ce moment, on en est plus à de la négligence mais à de la malfaisance. L'encapsulation est un outil qui permet aux développeurs de se protéger d'eux-même. Ce n'est pas un système de protection mémoire.

Tu mets ce que tu veux dans le set hein, tu peux faire plein de contrôle, discuter avec la voiture toussa.
Mais oui, ca simplifie l'usage. Si on part de ton principe, cad mettre la méthode changeWheel sur la voiture, faisons de même pour toutes les pièces remplaçable de la voiture (1000 ?), tu fais une façade géante de 1000 méthodes ou tu éclates en un graphe d'objets ?

En quoi serait-ce pertinent d'exposer les 1000 pièces de la voiture ? C'est typiquement le genre de cas où on aura besoin d'un mécanicien, un objet qui sait comment visiter la voiture et la modifier. Exposer une méthode pour chaque élément de la voiture briserait évidement l'encapsulation et serait stupide.
Quand au graphe d'objet interne de la voiture, il ne serait pas disponible pour l'utilisateur de la classe, mais uniquement pour des visiteurs.

Toutafé : on demande au parent (y'a pas le choix tu remplaces), et pas à l'ancètre le plus haut (le document) comme aurait dû y conduire la fameuse loi de Demeter.
Tu viens de montrer que tu n'as pas compris la loi de Déméter.

Par code, ça donnerait, pour remplacer un noeud :
doc.getNode('item3').getChildNode('title').setChildNode(2, new Node("fr-FR"))
Si on avait suivi la fameuse loi, tu aurais écris quoi ?

// Et encore, la fonction membre setChildNode n'a pas une signature géniale
doc.getNode('item3').getChildNode('title').setChildNode(2, doc.createNode("fr-FR")) ;

Je pense que tu as un sérieux problème à séparé les responsabilités. Ici, on veut modifier un arbre XML. C'est le métier du code, donc il n'y a pas de soucis à faire ce qu'on fait ici. Si le XML était plus spécialisé, on aurait des classes et des méthodes plus adaptés, à l'image de DOM HTML.

Arrête de théoriser, donne nous du code. Je m'évertue à montrer qu'en pratique cette loi ne marche pas, prouve le contraire en mettant l'équivalent de ce que j'écris.

Je ne théorise pas. C'est toi qui ne comprend pas ce qu'est la loi de minimisation des interaction d'un objet avec d'autres objets. La programmation est une affaire de compromis, ce qui fait qu'appliquer bêtement la loi de Déméter est absurde. Mais c'est tout aussi absurde de la jeter avec l'eau du bain.

Je sais que, au libre choix de l'implémentation, la copy de l'objet temporaire peut être optimisée. Mais franchement, je préfère des temporaires nommées, qui ne mettent pas en cause la cohérence de l'application.

Bah ca peut être le controller de l'application tout simplement.

C'est bien ça le problème, le tout simplement. On risque d'avoir beaucoup de complexité dans le contrôleur si on commence comme ça.

Se cacher derrière la sémantique de l'exemple, c'est petit :) Imagine toi le scénario que tu veux, l'API reste identique.

:D

Quelque soit la portion de code, il faut qu'ils soient modifiables : tu fais l'API de composants graphiques, tu ne sais pas qui ni comment il va l'utiliser. Tu dois par contre exposer tes services : accès composant, modification des composants, etc.

Oui, avec une classe qui expose ce qui est nécessaire et suffisant au pilotage du composant.

L'introspection ?

Je voulais parler des fonctionnalités utiles, pas des gadgets qui ne servent qu'à bricoler au runtime.

Le fait que pleins de type de base ne soit pas eux-même des objets ?

Ça dépend ce qu'on appelle un objet.

Le fait que des fonctions puissent ne pas être raccroché à des définitions de classe ?

C'est un avantage de C++ sur Java. De mettre toute le code dans une classe peut poser des problèmes d'encapsulation. Pourquoi une fonction facrory devrait absolument avoir accès aux membres privés ?

Le fait de pouvoir aller modifier n'importe quel objet avec un bête pointeur baladeur ?

Ça n'a rien à voir avec le caractère orienté objet du langage.

Le fait qu'il n'est pas possible d'exposer une API C++ avec des templates qui soit réutilisable ?

Exemple ?

La loi de Demeter a un objectif, certe louable, mais qui ne penses pas utilisateur : quand tu fais une API, tu la conçois de telle sorte qu'elle soit simple, intuitive et aisée à découvrir. Si on suit la loi de Demeter, on a une espèce de façade géante à tous les étages : non seulement l'objectif n'est pas atteint (pleins de méthodes proxy totalement inutiles, donc plus de code à maintenir) mais ca fait une API totalement bloated.

Ça dépend du type d'API que tu développe. C'est toujours le même problème : qu'est-ce qui peut être exposé, et à quel usage est destiné le composant.

Dans une API de voiture, je m'attend à pouvoir accéder au pneu sur l'objet roue que j'ai récupéré sur la voiture. Je m'attend pas à avoir 15000 méthodes directement sur mon objet voiture.

Récupérer le pneu, oui, puis le modifier et le remplacer. Mais l'assigner directement, c'est chercher les problèmes. Évidement qu'on peut mettre des observateurs dans tout les sens, mais est-ce que sa simplifie vraiment l'usage ?

Dans une API de composants graphiques, je m'attends à ce que la méthode de redimensionnement d'un objet soit sur l'objet concerné, pas sur son parent, son grand-parent ou sa soeur.

Moi aussi je m'attends à ce que le composant enfant ait cette fonctionalité. Mais lorsque tu composes une vue, et que l'ensemble de la vue nécessite des calculs particulier pour l'affichage, est-il pertinent de laisser n'importe qui venir modifier l'état interne d'un des composant.

Dans une API Xml, je veux pouvoir modifier un attribut d'un noeud directement sur le noeud et pas sur la classe Document.

Est-ce que modifier un nœud modifie l'état du parent ? Tu remarquera que pour remplacer un nœud, dans le DOM, on assigne pas le nœud ou on de modifie pas le nœud : on demande à son parent de le remplacer. Pareil pour créer un nouvel élément, on demande au document un nouveau nœud. Je crois que la loi de Demether a frappé là où tu ne l'attendais pas. D'ailleurs, ici, la logique métier c'est la gestion d'un arbre XML, et les méthodes exposées exposent bien les fonctionnalités de gestion de l'arbre.

Mais je penses qu'on est dans 2 façon différentes de penser :
* Je penses API, composants réutilisable par un tiers
* Tu penses objet et logique métier.
C'est pas forcement contradictoire, mais ce qui est sûr, c'est que la loi de Demeter est beaucoup trop théorique pour être applicable dans toutes les situations en pratique.

Je pense que c'est complémentaire, comme toujours, une succession de compromis.

Ce qui explique pourquoi tout les graphistes sont sous Mac.

C'est bien ce que je pensais. Il n'y a pas de problème à demander deux smart pointer en paramètres. Le problème vient quand on a un sagouin qui ne respecte pas le mantra « une opération, une ligne ». Parce que le problème que tu soulève, il existera quelque soit le nombre de paramètres prenant un smart pointer.

smart r(alloc()) ;
smart l(alloc()) ;
f(r, l) ;

Effectivement, je rajouterai aux problèmes d'empreinte mémoire que tu as évoqué, qu'on peut également invoquer le découplage entre l'objet utilisateur et un vecteur, et donc les problèmes d'ABI qui en découle.

#include <vector>
#include "people.hpp"

class Peoples
{
  std::vector<People> m_peoples ; 
}

#include <vector>
#include "people.hpp"

class Peoples
{
  std::vector<People> * mp_peoples ; 
}

Dans le premier cas, si on veut changer le conteneur on change aussi la structure et donc la taille de la classe qui encapsule le conteneur. Donc on casse l'ABI. Dans le second cas, ça n'a plus d'importance puisqu'un pointeur a toujours la même taille, quelque soit l'objet pointé.
Ceci dit, je pense que si l'ABI est un problème, on pimp la classe.

Prend un autre exemple, je veux redimensionner le bouton contenu dans une fenêtre :
app.getMainWindow().getContainer().getChild(1).resize(10,3)

Quel est le sens pour, un objet qui a accès à l'objet app, de modifier un détail de la représentation des données à l'écran ?

Tu crois que le container et la Window sont inccapables de se redimensionner automatiquement parcque je ne les ai pas notifié ?

Ben oui, ils savent pas, ils font pas. Sauf si tu as une loop qui tourne fear

t'aurais fais comment sans les get ?
app.resizeFirstChildOfContainerInMainWindow(10, 3) ?

Je ne le ferais pas car ça n'a pas de sens, dans le cas présent.

Comment prévoir tous ces cas ?

Est-ce nécessaire ? Est-ce qu'un composant graphique doit être modifiable par n'importe quelle portion du code qui l'utilise ?

Oué enfin si on pouvait éviter de prendre le C++ comme langage de référence quand on parle programmation objet ca serait pas mal :)

En matière de programmation orientée objet, il n'y a pas plus complet et avancé que le C++. D'aucun diront qu'il est même indigeste et incompréhensible.
En C++, tu as les interfaces (classes abstraites), les classes et fonctions membres finales (bon ok, là c'est vraiment bricolo), le polymorphisme sous toutes ces formes, l'encapsulation (contrairement à Python qui se prétend orienté objet alors qu'il expose tout), la programmation fonctionnelle, etc. Mais si tu vois un concept manquant, je suis tout ouïe.

Oui bien sûr, mais ça suppose que ta mercedes est la fonction de changement de pneu.
Donc si c'est une bibliothèque qui n'a pas prévu le coup, t'es mort, tu retournes voir le constructeur. C'est peut-être l'effet recherché tu me diras. Si t'es garagiste, tu peux avoir envie de bricoler sans t'en tenir aux seuls cas imaginer par le fabriquant.

Je suppose que tu voulais dire que la mercedes a la fonction :o)

C'est évidement l'objectif de la programmation orientée objet : des boîtes noires avec une interface pour faire des choses. Et si tu as besoin que la boîte noire fasse plus de choses, tu travailles avec le constructeur pour qu'il améliore la boîte noire. Sinon, comme tu l'as dit, ce sera du bricolage et la fiabilité de la voiture va légèrement en souffrir.
D'ailleurs, j'ai bien parlé de calcul de trajectoire dans mon message, et ce n'était pas anodin. La plupart des véhicules modernes tendent à nécessité un outil informatique afin de réaliser les opérations de maintenance courante comme la vidange. Alors le changement de pneu !

En fait, depuis tout à l'heure, je cherchais un endroit où je pourrais imaginer utiliser un new sur un std::vector… ben j'ai pas trouvé :o) Je crois qu'en fait, je n'ai jamais instancier de vector dyamiquement parce que ça n'a pas de sens. Mais bon, mon but était de pointer le fait que les conteneurs ne sont pas conçus pour être dérivés.

Quel est le problème de passer deux smart_ptr en paramètres d'une fonction ?

Tu confonds annonce et recherche réelle, c'est bien ce qui biaise le résultat. Et non, ce n'est pas normal qu'il y ait du roulement. Il y a quelque chose qui ne va pas dans le management s'il y a autant de turn over.

Tu viens d'exposer le gros problème des accesseurs bêtes sans réflexion. Tu changes le pneu sur la roue, sans notifier la voiture que tu as changé le pneu. Comment la voiture le sais ? Si le calcul de la trajectoire dépend de la qualité du pneu, ça peut être un problème si l'implémentation de la voiture n'utilise pas l'objet roue qui aura été retourné. C'est clairement un problème d'encapsulation.

Et vu qu'en C++, on renvoie généralement des références sur const, ben, ton objet accédé ne sera pas mis à jour.

Moi je verrais plutôt un truc comme ça :

Voiture mercedes = parking.sortirVoiture("111 AAA 111") ;
try
{ mercedes.changeRoue(0, PneuMichelin(12, 10)) ;
} catch(PneuIncompatible const &e) {
  // annuler la commande ?
}
parking.rangerVoiture(mercedes) ;

Tu remarqueras qu'il n'y a pas d'accésseurs, mais uniquement des méthodes métier. Je pense que les accesseurs ne sont pas une bonne idée. Évidement, c'est Java qui a popularisé la méthode.

Ce qui est très propice aux erreurs ;) Bref, hérite en privé, et le problème ne se posera plus. Tu réutilisera std::vector, mais tu en changeras la sémantique. Bref, beaucoup de boulot pour utiliser std::vector<>::operator [] au lieu de std::vector<>::at ;)

Pourquoi allouer dynamiquement un conteneur standard c'est mal ?
Est-ce qu'allouer dynamiquement un type composé avec des conteneurs standards est mal ?

Je suis preneur de n'importe quelle source (papier, web). Et ne parle pas de performances (un le contenu géré par le vector est alloué sur le tas) ou le problème de la gestion de la désallocation (std::auto_ptr est mon premier ami).

Est-ce que tu essayais d'illustrer le slicing problem avec ton exemple ? Je ne vois pas le rapport avec le taboo de l'allocation de conteneurs (et c'est quoi cots ?).

C'est quoi une DLL ? :o) Plus sérieusement, c'est le genre de fonctionnalité qui peut être soumis à débat dans la spécification d'un langage. Ainsi que les threads, les IPC, etc.

L'initialisation des variables statiques est défini par la norme : au choix de l'implémentation :D La taille des types est définie, elle n'est pas bornée, c'est tout.

Ce n'est pas la question. Les technologies Java permettent de d'embaucher des armées de développeurs moyens, tout en assurant une qualité correcte des logiciels qui sont issus de ces armées. Alors qu'avec le C++, il faut plus de compétence et de bouteille pour parvenir à un résultat de qualité équivalente. Évidement, il y a une différence de coût.

J'espère que tu ne te bases pas sur les annonces sur les sites d'emploi ? Parce qu'il est normal que les banques cherchent en continu : ils ne trouvent plus de développeurs Cobol ou Fortran :D

Je te conseille la lecture des bouquins de Meyers, qui te permettraient de comprendre que ce que tu viens d'écrire, c'est de la merde.

int main()
{
   std::vector<int> *pv = new MyVector<int>;
   pv->push_back(5);
   try {
      std::cout << (*pv)[1] << std::endl;
   } catch (const std::exception & e) {
      std::cout << "received exception" << std::endl;
      return 1; // undefined behaviour
   }

   delete pv ; // explosion en vol
   return 0;
}

La norme, tu sais, le document qui décrit peu ou prou le langage C++ (comprenant la STL), spécifie clairement que les conteneurs standards ne sont pas dérivables publiquement. Tu es tombé dans le piège à débutant. Welldone.

Ici, le soucis est évidement que les conteneurs standards ne définissent pas de destructeur virtuel, ce qui fait que la classe template n'est pas conçue pour être dérivée.

Au pire, tu aurais pu composer avec l'héritage privé, s'eut été acceptable, mais ta classe dérivée n'aurait plus été un std::vector.

Rien que sur le sujet en discussion, regarde la signature de func.apply(...) où tu dois passer un "this" à null si la fonction n'est pas une méthode. Joli hein ?

Non, tu passes l'objet cible null si la fonction appelée ne nécessite pas un objet. En javascript, il n'y a pas de notion de fonction membre.

Donc pour revenir au sujet, je ne connais aucun développeur Python confirmé qui ait un problème avec le "self" explicite, et qui voudrait le retirer. Je pense au contraire que cela rend intégralement explicite le contexte d'exécution, ce qui est une qualité.

Moi ça m'emmerde de le taper à chaque fois. Surtout qu'on peut lui donner le nom qu'on veut, ce qui laisse libre court à l'imagination des marauds. Je préfère largement le mode C++ : on utilise les variables dans le scope, et les variable d'instance y sont jetées. Histoire d'éviter de répéter en permanence qu'on se modifie. L'indentation significative ne me pose pas de problème, tant que tout le monde utilise des tabulations équivalent à 4 blancs. Je sais, ce n'est pas pythonique, set expandtab.

Tout les formulaires de soumission doivent contenir un token aléatoire et unique lié à une session s'il permet la modification de l'état de l'application.

http://en.wikipedia.org/wiki/C%2B%2B0x#Type_inference

Ça dépend de quel C on parle. Les améliorations de C99 ne sont pas toutes disponibles dans C++01, et pas plus dans C++0x.

Par design, std:vector<> n'est pas dérivable. Tu ne peux que composer avec std::vector<>.