LupusMic a écrit 1481 commentaires

Ils sont indispensables, puisque leur absence entraîne une impossibilité d'encapsuler. L'encapsulation, c'est rendre étanche l'état interne d'un système de ces clients, et de fournir aux clients une interface de manipulation.

Bien évidement, les modificateur de visibilité ne garantissent pas l'encapsulation. Nombreux sont les imbéciles à générer automatiquement des getter qui exposent induement un composant interne à l'extérieur. Comme par exemple, le dernier getter proposé dans cet exemple :

class State
{
    /* ... */
} /* class State */;

class BlackBox
{
        class Impl;
        std::unique_ptr<Impl> p_impl;

    public:
        BlackBox();
        BlackBox(BlackBox const &);
        BlackBox & operator=(BlackBox const &);

        // Une copie de l'état interne de l'objet
        State const state() const;

        // Optimisation du précédent, mais avec une brèche qui peut mener à la
        // manipulation de l'état interne de l'objet
        State const & state() const;

        // Une exposition directe de l'état interne de l'objet
        State & state();

} /* class BlackBox */;

On voit bien que dans le premier, la manipulation de l'état interne de l'objet n'est pas possible sans reverse engineering. Dans le second cas, un const_cast est possible, c'est parfois ça le coût de l'optimisation. Dans le dernier cas, c'est la fête du slip : il n'est plus possible de changer d'état sans effet de bord. Sauf à limiter fortement la conception interne de la classe, et c'est là qu'on voit que l'encapsulation n'est plus.

Tu me diras qu'en Python, on s'en fout, on manipule des références.

# abstract
class State(object):
    pass

class InitState(State):
    message = 'Initial'

class TermState(State):
    message = 'Terminal'

class BlackBox(object):
    def __init__(self):
        self._state = InitState()

    def state(self):
        return self._state

    def next_state(self):
        if isinstance(self._state, TermState):
            raise BaseException('Mais euh!')

        self._state = TermState()

def client():
    bb = BlackBox()

    # Aquisition d'une reference sur l'etat interne de l'objet (note que ce commentaire est
    # errone)
    current_test = bb.state()

    while current_test.message is 'Initial':
        bb.next_state()

client()

Au temps pour les références et leur usage incorrect… Alors oui, il est possible de faire la même connerie en C++, conserver l'état et le réutilisé plus tard. Mais la grosse différence, c'est qu'en C++ tu sais que tu acquiert une copie, et que donc c'est copie a une durée de vie courte.

C'est pour ce genre de conneries que j'aime l'encapsulation, l'hermétisme des systèmes et la rigueur.

En effet, ça structure énormément. Je n'oublie plus ce maudit point-virgule depuis des années, et l'utilises pour documenter.

class turlute
{
/* bwaaaaaaaaaaaaah */
} /* class turlute*/ ;

Ils récoltent depuis un bout de temps des informations de leurs utilisateurs pour savoir comment firefox est utilisé. Cette case n'est pas utilisé

Donc ceux qui acceptent de se laisser espionner ne désactivent pas le JS, comme c'est étonnant !

Vu que StackOverflow pollue la moindre recherche sérieuse, c'est vite vu :p

C'est une extension propriétaire de Google Chrome en fait. Quand dans la barre d'URL tu tape scheme:, le navigateur Web doit respecter le scheme invoqué.

sinon, ce n'est plus un navigateur Web.

En fait là je parlais en général. Et puis tu peux utiliser les accolades en Python! :p

Non, les accolades, en Python, c'est pour les dict.

Lapin compris (j'ai fait très très peu de PHP).

Dans l'exemple suivant, au niveau global, answer nomme une constante, une classe et une variable.

<?php

const answer = 42;

class answer {
    private $answer;

    function __construct($answer)
    {
        $this->answer = $answer;
    }

    function answer()
    {
         return $this->answer;
    }
}

$answer = new answer(answer);
var_dump($answer->answer());

Ou sinon on privilégie l'efficacité à l'esthéthique, et des fois savoir que c'est une constante au premier coup d'œil ça peut être pratique.

Dans le cas de PHP, la question ne se pose pas, car le contexte indique directement qu'on a une constante. Ceci dit, je ne vois pas pourquoi je devrais considérer une variable différemment selon que c'est une constante ou non. Dans le cas de Python, c'est trompeur, puisque les constantes n'existent pas.

J'avoue que je n'ai pas (encore) rencontré d'exemple de duck typing.

Oh si, tu as dû. Le ducktyping vient d'une idée très simple : jusque là, tout va bien. En fait, tant que l'objet que tu manipule se comporte comme ce à quoi tu t'attends, tout va bien. En gros, ce qui marche comme un canard, est un canard. Bref, une oie est un canard par exemple. C'est génial quand tu fais un prototype, mais ça devient un enfer sur un projet plus important.

Si les gens font de la merde aussi, ils peuvent en faire dans tous les langages.

Non. C'est une erreur habituelle à mon sens. Un langage exigeant ne permettra pas à l'incompétent de croire qu'il peut écrire une application de facturation en quelques clicks. Apprendre des langages exigeant comme Ada ou C++, ça permet de structurer sa pensée, ce qui permet d'utiliser des outils plus laxistes pour prototyper. Mais au final, il faudra bien structurer.

Pour le reste, on peut utiliser des outils comme Pylint, ou même le compiler vers un autre langage (C, Java, C#).

Les outils pour analyser le code sont légions, et très utiles. Je les utilises systématiquement, et en compléments les tests unitaires et fonctionnels. Quand à compiler, je ne vois pas l'intérêt de compiler du code bancal : tu n'auras pas magiquement le type hinting, par exemple.

Les conventions disent d'indenter proprement

Ce n'est pas une convention. Un programme Python est naturellement indenté, car l'indentation est utilisée pour distinguer les blocs de code, là où le C (et inspirés) utilise des accolades.

de mettre les noms de constantes en capitales

Ce qui est un aberration. Il ne peut pas y avoir de constante en Python, donc aucune variable ne peut voir son nom être capitalisée… à moins d'utiliser un décorateur, j'avoue.
Ceci dit, j'ai arrêté de capitaliser les constantes :

• en PHP, il ne peut y avoir de collision variable/constante, donc l'absence de $ ou de () suffit à distinguer une constante des autres symboles.
• en C/C++, les macros devraient être en captales. Si en C les constantes sont par incidence des macros (#define), ce n'est pas la culture en C++ (où on utilisera const sur des données statiques membres ou des variables globales). Je sais, un vilain peut toujours faire un const_cast, mais il faut le taper, et ça se voit (et je ne crois pas qu'un const_cast sur une globale constante soit un comportement définit).
• en Python, parce que finalement, il y a toujours un couillon pour venir affecter une nouvelle valeur à ta constante. Je préfère encapsuler et fournir des copies de la valeur, histoire d'être certain que personne ne vienne y foutre le bordel.
• en JavaScript, comment dire, c'est, hmmm

• en SQL, j'ai même arrêter d'écrire les clauses en majuscules. Un jour, j'essaierai de comprendre pourquoi tout le monde écrit ses requêtes en majuscules.

  C'est moche les majuscule, et c'est la seule raison pour laquelle j'ai réellement bannit les allcaps.

Je t'écoute.

Les pythonistes prétendent privilégier l'explicite sur l'implicite. D'où découle, entre autres absurditées, l'inutile self comme argument de chaque fonction membre.

Pourtant, il y a des choses implicites. Par exemple, les invariables sont copiés quand passés en argument, ou encore assigné à une variable. Le ducktyping : il n'y a pas plus implicite que le ducktyping, puisque tu suppose que l'objet qui t'es donné réagi comme tu t'y attends. L'absence totale de typehinting : ce qui est explicite, c'est de dire quel type/interface tu attends en argument, pas de le dire vaguement dans le doc ou laisser le plaisir de la lecture de la fonction.

et de ne pas utiliser des variables membres préfixées de _ en dehors de la classe (en plus c'est pratique de le savoir au sein de la classe en un coup d'œil).

Et pourquoi ne pas utiliser l'hungarian notation tant qu'on y est ? J'utilise _ pour préfixer, j'ai même essayer _classname_varname pour améliorer ça, mais ça reste encore de la convention, on peut saloper depuis l'extérieur de la fonction.

C'est pas dur. Mauvais dèv, changer de dèv.

Entendons-nous bien, je considère qu'un langage de programmation est un outil pour exprimer des idées, des concepts. S'il faut passer des heures pour une erreur de typo (oh, mais c'est length, pas lenght) parce que le langage est laxiste, je dis non. je veux que mon programme échoue le plus tôt possible, pour que je puisse corriger les problèmes, je ne veux pas que le programme tombe en marche et erre dans un état indéterminé.

On peut ensuite s'amuser à contrôler chaque argument de chaque fonction, qu'il expose la bonne interface, que l'attribut machin expose la bonne interface, etc. Mais franchement, pourquoi est-ce que c'est à moi de contrôler ça manuellement en 3 lignes de code alors que le langage peut être utilisé à cette fin ?

L'encapsulation des données est un principe fondamental de la programmation orientée objet, et que je considère comme central. Python ne propose pas de tels mécanismes, mais propose uniquement d'adopter une convention qui sera violée comme toutes les conventions. Ce n'est pas une encapsulation propre.

La programmation objet à pour but d'encapsuler des mécanismes et d'en exposer une interface simple d'utilisation. S'il est possible facilement de venir foutre le bordel, il n'y a plus d'intérêt à faire de l'objet.

Quand à la devise de Python, elle est tellement ridicule que je ne comprends toujours pas comment des gens peuvent continuer à la défendre. Surtout dans un langage où l'implicite est malgré tout très présent.

Au départ je n'avais pas vu la partie sur Nginx, mais je me suis dit que le troll vallait quand même, un peu.

Plus sérieusement, ce n'est pas le boulot de l'application d'expliquer comment on configure un autre logiciel. Ou alors, dans un tutoriel, mais à part du logiciel principal.

C'est pourtant assez lié, on a tendance à developper les compétences qu'on espère utiles au travail, pour faire la différence ou avoir un travail pour manger.

Par contre, pour l'hébergement virtuel, l'argument ne vaut pas. Tu installe ce que tu veux sur un virtuel puisque c'est une machine complète. Et Python (ou Ruby, ou autre Perl) ne mange pas plus de ressources qu'un déploiement PHP, et mod_wsgi est assez équivalent à un déploiement PHP.

Ouais, tu sais que je fais partie de cette plèbe de demeurés ;)

Mustache !

Avant d'utiliser un Framework, il faut déjà maîtriser PHP.
Utiliser un Framework, c'est choisir une architecture, se limiter à un sous-ensemble de PHP.

Personnellement, aucun framework PHP ne me plait. Python n'est pas objet (pas de modificateurs de visibilité, donc pas d'encapsulation, donc pas objet), et surtout avant de pouvoir déployer du Python, il faut réfléchir plus que pour du PHP.

Si PHP continue à avoir tant de succès, c'est parce que n'importe quel demeuré peut immédiatement publier son script troué sans effort. Ce qui rend donc la technologie moins cher, puisqu'on peut embaucher des imbéciles qui feront des scripts pas plus pourris que les autres.

:)

Becaucoup de choses ne fonctionnent pas, ça n'aide pas de ne dire que ça pour les résoudre.

Mon Chrome semble ne pas trouver la ressource, par contre w3m télécharge sans problème la ressource.

Bon, comme d'habitude, je suis allé regarder le code source. Et je n'ai pas été déçu. je ne vais m'étendre sur l'usage du français et des caractères UTF-8, l'ami Nicolas semble joueur.

Utilisation de données externes sans contrôle :

<?php  return $protocol . "://" . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];

curl_init n'échoue jamais, pas plus que ces petis copains il faut croire ;)

<?php
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $url);

inc/functions.php:60

<?php
$httpcodeOK = isset($httpcode) and ($httpcode == 200 or $httpcode == 301);

Quelque soit la valeur numérique de $httpcode, $httpcodeOK sera vrai. La raison en est la précédence des opérateurs (l'affectation est prioritaire sur les opérateurs 'and' et 'or').
'and' n'est pas l'équivalent de '&&'.

J'aime beaucoup le salt public dans inc/config.php

La classe Store devrait être une interface.

Je ne comprend pas pourquoi le constructeur du parent (vide en plus) est appelé dans certaines méthodes de la classe SQLite.

Plus généralement, tu indique dans la documentation :

You have to protect your db/poche.sqlite file. Modify the virtual host of your website to add this condition

Déjà, tu considère que tout le monde utilise Apache ou Nginx, ce qui est une erreur. Ensuite, tu t'appuye sur un cache-misère pour éviter un accès direct au fichier de base de données. Une bonne pratique est de fournir un répertoire public, qui est exporté par le serveur web, plutôt que d'exporter tout le répertoire applicatif.

La regex sur les email est fausse :'( Une bonne pratique est d'utiliser filter_var plutôt que de faire le malin avec une regex pourrie.

functions.php pourrait avoir un nom un peu plus parlant.

Allé, j't'ai fait un p'tit Pull Request.

man sed
man awk

Maintenant, tu peux vouloir utiliser des fonctions avec des effets de bord,

C'est exactement ce que j'avais en tête. Du genre, les objets passés à traiter désignent des ressources qui dépendent d'autres ressources. Pour moi, un exemple typique serait de parcourir un système de fichier avec un critère. Si la lecture de la mémoire apparaît comme infaillible aux yeux de certains perdus dans l'idéal programmatique, que le disque dur puisse merder est moins étrange.

Merci en tout cas pour l'exemple de « fail over ».

Mon premier contact avec map/reduce était avec MongoDB. Le fait qu'un serveur à qui on a délégué un mapping échoue n'est pas quelque chose d'inexistant. C'est pour ça que je pose la question.

Et il y a toujours des bogues, statistiquement. Prétendre qu'il n'y en a pas parce que c'est prouvé mathématiquement, c'est de la branlette universitaire.

Je viens de me faire un petit programme pour me rendre compte de ça. Je n'avais, pour l'instant, pas compris std:async et compagnie.

En fait, il y a pas mal de travail à accomplir pour obtenir le même type de traitement qui est fait nativement par Haskell. Mais ce n'est pas insurmontable.

Par contre, je me dis qu'il peut arriver qu'une opération map échoue, et ait besoin d'être retentée. Est-ce que Haskell permet de définir la politique de failover ? Où on s'en fout ? :D

En tout cas, merci pour ta contribution à mon élévation intellectuelle, c'est toujours appréciable.

Est-ce que c'est le genre de problème que permettent de résoudre std::future et std::async ?

Pour son micro-ondes Raspberry Pi ?
http://techcrunch.com/2013/07/11/raspberry-pi-microwave-hack/

Je me suis mal exprimé. Il n'est pas possible de représenter directement un nombre décimal, sauf entiers, en nombre binaire comme on le fait avec les nombres entiers.

Il faut adopter une représentation différente, comme avec le BCD que tu indiques (et que je ne savais pas exister, mais c'était à peu près ce que j'avais imaginé pouvoir faire), ou sacrifier de la fiabilité sur l'autel de la performance (note que je n'ai rien contre le fait d'utiliser les float en science, où il faudra incorporer leur imprécision dans la détermination de l'imprécision du résultat).

En fin de compte (sic), on est assez d'accord. C'est juste que tu considère qu'un centime d'erreur dans un compte de plusieurs centaines de milliers de franc ce n'est rien. Mais mon tympant se souvient encore du mécontentement d'une cliente, qui a passé avec moi des heures au téléphone pour un centime d'erreur, simplement parce que les bons comptes font les bons services publics. :D

Prends moi pour un con. Comme si je ne saivais pas qu'on avait inventé les nombres flottant parce que les ordinateurs ne comprennent pas les décimaux du système décimal de manière native, et que donc il faut ruser pour avoir des calculs exacts.

Microsoft Excel, à l'instar de bases de données relationnelles, de Python, de la libbc, etc, doit certainement offrir un support des nombres décimaux de manière exacte. Qu'ils utilisent les float dans leur soupe n'est pas un problème, si les algos employés permettent de détecter les cas limites.

Disons que j'ai déjà vu des applications où tout était compter en float, et évidement, à la fin, les comptes étaient faux en raison de l'emploi de float dans le code.

Il y a une obligation légale à ce que les comptes soient exacts.

Finalement j'ai retrouvé : https://linuxfr.org/nodes/98225/comments/1450176