Sur une idée de @Kysofer, je reprends mon post précédent pour mettre à jour l'exemple que j'avais donné afin de l'améliorer et de le simplifier.

L'idée est de se débarrasser des méthodes 'static' de chaque structure que j'avais appelées "new" pour les remplacer par des fonctions globales (globales au niveau du module) à côté des structures et dont le nom est plus porteur de sens. (ndr. elles remplacent les constructeurs nommés de Yegor Bugayenko en prenant un petit peu de la Factory Method défendues par Joshua Bloch).

L'intérêt des d'avoir des objets concrets qui profitent tout de suite du polymorphisme d'une interface (ici "Addition") et de wrapper ces instances dans une Box<dyn T> pour être réutilisées ailleurs, y compris dans une struct. Cela découple totalement les liens entres les instances puisque seules les types des interfaces fuitent.

Si à cela on ajoute l'immutabilité totale et l'absence de getter/setter, alors cela commence à être du vrai FOP (Functional-Object Programming) dont la base s'appuie sur la notion d'Elegant Objects.

Je suis contente de savoir à présent allier parfaitement paradigmes fonctionnel et objet alors qu'ils m'ont toujours été présentés comme deux antagonistes.

L'étape suivante sera de compléter l'exemple pour effectuer le même calcul en multi-thread et tirer 100% de la puissance de Rust. @Kysofer, si tu as l'envie de m'aider :P

#![allow(non_snake_case)]
// Exécution
fn main() {
    let additionA = AdditionFromCouple(1, 2);
    println!("Couple add  : [{}]", additionA.add()); // Print 3

    // Ne pas oublier de wrapper Couple dans une Box
    let additionB = AdditionFromTriplet(additionA, 3);
    println!("Triplet add : [{}]", additionB.add()); // Print 6
}

// Traits
trait Addition {
    fn add(&self) -> i32;
}

// Structures
struct Couple {
    opA: i32,
    opB: i32,
}
struct Triplet {
    opA: Box<dyn Addition>,
    opB: i32,
}

// Implémentations
impl Addition for Couple {
    fn add(&self) -> i32 {
        return self.opA + self.opB;
    }
}

impl Addition for Triplet {
    fn add(&self) -> i32 {
        return (*self.opA).add() + self.opB;
    }
}

// Factory Methods (Utilisées comme constructeurs) 
fn AdditionFromCouple(opA: i32, opB: i32) -> Box<dyn Addition> {
    return Box::new(Couple { opA: opA, opB: opB });
}

fn AdditionFromTriplet(opA: Box<dyn Addition>, opB: i32) -> Box<dyn Addition> {
    return Box::new(Triplet { opA: opA, opB: opB });
}

Comment faire sauter l'activation d'un Windows XP (ou tout autre OS pour lequel Microchiotte a arrêté ses serveurs, quand on vous que le libre vous protège).

Sinon je suis toujours sur mes tentatives de faire marcher StarCraft sous Linux, la version "normale" ne parvient pas à switcher en affichage 8-Bits sous Wine, la version "remastered" n'est juste pas prise en compte #PureSadness

D'autant que j'avais acheté la version "cartooned" pour mes petits :(

Au passage si quelqu'un sait comment je peux demander à Xephyr d'être en plein écran avec une résolution 640x480 je prends !

@OpenNews lol on ne s'est peut-être pas compris.

L'argument de scandinave (qui m'avait touché) n'était pas de défendre ou d'attaquer les médias ou les réseaux sociaux pour prétendre qu'untel est meilleur ou moins bon que l'autre mais de montrer à travers ses deux exemples - qu'il a volontairement rendu grossiers afin d'illustrer sa pensée - que la notion de vérité n'existe pas en tant que valeur absolue et c'est en ce sens que j'ai repris son post.

Denzel Washigton l'explique très durant les 30 premières secondes de cet extrait que je peux synthétiser/traduire en ceci :

Si vous ne lisez pas la presse alors vous n'êtes pas informé mais si vous lisez la presse alors vous êtes désinformé. [...] Quels sont les conséquences à long termes d'un excès d'information ? [...] Les médias actuels tentent d'êtres les premiers [ndr. à sortir une news] pas de rapporter la vérité [...]

C'est pour cela que j'ai rebondis sur son post car je crains la création d'un "ministère de la vérité" mais qui s'instaurerait de manière insidieuse et quasiment invisible via des articles du genre de celui sur lequel répondait scandinave. Cela a déjà commencé en France avec le Decodex du Monde qui s'était attaqué au site les-crises.fr sans fondement, juste parce que les sites de "fact-checking" ne sont ni plus ni moins qu'un support permettant d'encourager les citoyens à écouter et croire quelques uns au détriment d'autres et ceci sans la moindre preuve, seulement en les pointant du doigt.

D'ailleurs le youtubeur Trouble Fait l'explique parfaitement dans sa vidéo Fake News : L’assaut de la police de la pensée (31 min à voir, foncez) en dénonçant le grand retour du Maccarthysme.

Pour reprendre les propos de l'article, ok admettons que les gens qui dépendent des réseaux sociaux sont moins bien informés (sous-entendus que ceux qui dépendent des grands médias, grands médias qui sont détenus - à perte - par une poignée de milliardaires hein). Mais quel est le critère ? Quelle est l'unité ? Comment se font les mesures permettant de dire que quelqu'un est plus ou moins bien informé qu'un autre !? Une ligne politique ? Une doctrine religieuse ? Une morale "vertueuse" ? lol

La critique de scandinave montre de manière subtile que l'article posté sur developpez.com est un article politique, basé sur une pseudo-étude dont la rigueur est à la science ce que l'homéopathie est à la médecine.

Bref, j'aurai dû être plus explicite dans ce que je souhaitais mettre en exergue dans mon post d'origine. En tout cas merci à toi qui a pris le temps de me lire et de me répondre.

Alerte au gogol ! Alerte au gogol les enfants

Boursorama en ajoutant des trackers de serveurs de pub sur son site permet à des sociétés tierces d'accéder aux comptes de ses clients. Bravo, zetes des champions...

C'est un scandale, information à faire tourner autant que possible en espérant que le bad-buzz leur serve de leçon !

@Sweet le 9 c'est le plus compliqué quand on vient du procédurale et qu'on essaie de faire de l'OOP (note : l'API Java est procédurale à 99%).

Je l'ai compris grâce à des formations que des copains d'ITAMETIS m'ont offertes (merci @Kysofer pour tout le temps que tu as passé à m'appendre). En substance, dès qu'une classe affiche un getter ou un setter, alors son développeur a violé le principe d'encapsulation, ce qui est "anti-objet" par nature.

Dit autrement, nous mettons des get/set pour avoir bonne conscience mais nous pourrions les remplacer par des attributs public cela reviendrait exactement au même. En ajoutant des getter/setter nous exposons deux choses en les sortant de l'encapsulation :

1. La valeur de la donnée
2. Le type réel de la donnée (c'est de loin le pire)

Et ce type d'objets s'appelle : une structure de données. Les méthodes des autres objets appelant les get/set n'étant que des procédures décidant quoi mettre et quoi retirer de ces objets structures de données.

Alors cela m'a pris un bon moment avant de comprendre comment coder sans setter (pour l'immutabilité de la programmation fonctionnelle) et sans getter (pour respecter l'encapsulation de la programmation orientée objets) ; et bien sûr sans jamais remplacer l'un ou l'autre par des attributs publics. C'est ce que j'entends lors que j'écris "programmer en interface-first".

Le meilleur bouquin que je puisse te recommander à ce sujet est Elegant Objects de Yegor Bugayenko. C'est un solid 5/7 au niveau de la "disruptivité". Mais si tu fais du Java par exemple, alors tu devrais comprendre pourquoi ceux qui font "du vrai" OOP (pardon pour l'expression mais c'est à prendre au sens "ne violant jamais l'encapsulation") disent que Spring n'est pas orienté objet pour un sou et que le framework pousse à de la programmation procédurale comme en C ou VB.

Après c'est mon côté coach crafts qui incite toujours à mieux comprendre un paradigme de programmation et d'expérience maintenant, la grande majorité des développeurs ne creusent pas plus loin que les 75% d'un concept (ça descend en dessous des 20-25% pour l'objet et le fonctionnel car les "frameworks s'en occupent pour nous") et puis il faut aussi admettre que le procédurale est bien plus accessible quand on veut produire vite, même s'il est nettement moins maintenable.

J'avais entendu le nom il y a quelques années mais n'ayant pas plus creusé le concept je l'avais oublié. Le hasard du destin me fait retomber dessus aujourd'hui. Bref il s'agit de 9 règles de programmation à appliquer.

En résumé :

1. N'utiliser qu'un seul niveau d'indentation
2. Ne pas utiliser le mot-clef ELSE
3. Encapsuler toutes les primitives et les String dans des objets
4. Encapsuler les collections dans des objets
5. N'enchaîner qu'un seul point (ou flèche) par ligne
6. Ne pas utiliser d’abréviations
7. Garder des classes petites (moins de 50 lignes)
8. Aucune classe ne doit avoir plus de deux instances en guise de variables
9. Ne jamais utiliser de Getter/Setter

Globalement, je le fais sans m'en rendre compte, mes classes sont minuscules (20 lignes en moyennes). Éventuellement le ELSE m'est encore utile mais c'est vrai que programmant en fail-first je lui préfère un throw direct et donc qu'il n'apparaît vraiment pas souvent.

Note personnelle : je n'aime vraiment pas du tout la syntaxe de Rust, mais vraiment :(. À chaque fois que j'en fais je meurs un petit peu. Après je maintiens qu'il s'agit d'un des meilleurs langages du marché à cette heure et une tendance de fond qui me pousse à prendre la vague.

Bon je vais reprendre le début du kata @Kysofer (qui va me faire intervenir dans ses formations) pour montrer comment il programme en OOP "pure" avec Rust en mettant en place une encapsulation stricte (à la Yegor Bugayenko). Le poste se fera en plusieurs parties, cette première étape consistant à montrer comment fonctionnent les trait, les struct et la notion de value borrowed pour les débutants.

Objectifs du kata :

• Fournir deux structures différentes permettant l'addition.
• Décorer la première structure par la seconde.
• Introduction succincte au value borrowed.

Code :

#![allow(non_snake_case)]        // Oui je viens du monde Java/Kotlin

// Structures
struct Couple {
    opA: i32,
    opB: i32,
}

struct Triplet {
    opA: Couple,
    opB: i32,
}

// Interface
trait Addition {
    fn add(&self) -> i32;
}

// Implementations
impl Addition for Couple {
    fn add(&self) -> i32 {
        return self.opA + self.opB;
    }
}

impl Addition for Triplet {
    fn add(&self) -> i32 {
        return self.opA.add() + self.opB;
    }
}

Exécution :
Pour instancier et exécuter le code il faut écrire ceci. Tout marche, aucun problème.

fn main() {
    let additionA = Couple { opA: 1, opB: 2 };
    println!("Couple add  : [{}]", additionA.add()); // Print 3

    let additionB = Triplet {
        opA: additionA,
        opB: 3,
    };
    println!("Triplet add : [{}]", additionB.add()); // Print 6
}

La petite difficulté (el famoso "value borrowed") arrive dès que l'on initialise les deux structures l'une derrière l'autre :

fn main() {
    let additionA = Couple { opA: 1, opB: 2 };

    let additionB = Triplet {
        opA: additionA,
        opB: 3,
    };

    println!("Couple add  : [{}]", additionA.add()); // NE COMPILE PAS
    println!("Triplet add : [{}]", additionB.add());
}

En réalité, au moment du premier println!(), la variable additionA n'est plus dans l'espace courant mais a été empruntée par Triplet, elle se retrouve donc utilisable mais uniquement par lui. Alors soit on réordonnance le code (ce que j'ai fait dans la première exécution qui fonctionne) soit on indique que Triplet restitue la variable qu'il a emprunté (je montrerai plus tard comment faire).

Bref, jusque là rien de transcendant nous remarquerons quand même que Triplet contient un Couple (c'est-à-dire une structure) et non une Addition (c'est-à-dire une interface) ce qui matérialise un couplage fort entre les types et donc l'impossibilité de programmer par contrat (c'est-à-dire en masquant les implémentations et en protégeant l'encapsulation des données contenues dans la structure Couple).

C'est là qu'arrivera la second difficulté dont je parlerai aussi plus tard : comment calculer dynamiquement les tailles des implémentations des traits pour les utiliser en tant qu'attribut d'une structure.

Avis personnel : depuis quelques mois que je m'amuse avec Rust je peux dire que globalement j'aime ce langage mais cela ne m'empêche pas de le trouver pauvre sur pas mal de ses aspects (au sens paradigme de programmation).

Dans ce qui me déplaît, je mettrais la forte emprunte qu'il retire C et du C++, notamment leur style procédurale omniprésent (on ne code plus comme en Pascal en 2020, damned), l'encapsulation découragée totalement (en ce sens Rust n'est pas objet pour un sous, et la programmation en structure-first est un anti-concept, encore une fois cf. Elegant Objects de Yegor Bugayenko) et pour ma plus grande tragédie, une syntaxe que je trouve lourdingue car s'appuyant sur beaucoup de symboles ou trop peux expressive (je suis navrée pour ceux qui pensent que i32 et u32 sont de bonnes façons d'écrire des entiers signés ou non en 2020).

Encore une fois, la syntaxe de Kotlin (sauf le sucre syntaxique du préfixe get/set et les equals methods), l'API immutable de Kotlin, la gestion des Threads/KoRoutines de Kotlin, le null-check de Kotlin, le tout mêlé au Owernship de Rust, à la performance du binaire produit par son compilateur, à sa capacité à gérer du bas niveau, tout ceci en ferait sûrement l'un des langages les plus efficaces et fiable du siècle.

Je prie pour que Kotlin Native soit un "game changer" notamment pour qu'il parvienne à s'élever au niveau de Rust en terme de performances et de protection contre les race-conditions.

Sans blague... Utiliser un des compilateurs les plus difficiles du marché (ici Kotlin) prévient une grande partie des bugs et réduit leur nombre de 33%, le cas présent sur l'application Google Home depuis Que Goole a remplacé le code en Java par Kotlin.

C'est un peu comme si les langages interprétés et sans contrôles ultra-stricts à la compilation étaient moins efficaces... La surprise est totale ! (Ô__Ô) #Kotlin #Rust

Tiens j'entends comme un écho qui dénigrerait Python... Et quelqu'un d'autre qui tousse très fort JS/NodeJS... Vraiment bizarre, allez savoir pourquoi #TrollInsideOuPas

Comprendre comment associer les couleurs entre-elles.

J'apprécie fortement l'effort fait par le vidéaste pour expliquer l'ensemble des types d'associations possibles en les illustrant par des exemples simples.

Sinon je me remets au dessin que j'avais mis en pause depuis quelques temps par manque d'inspiration. Merci à @Strawberry qui fût à l'origine de ce redémarrage même si elle ne se doute de rien.

@Bill2 : j'ai tout écouté ce soir, merci sans toi je serai passée à côté.

Bon le côté suffisant d'AstronoGeek m'a toujours énervée mais honnêtement les deux vidéos sont très bien, l'argumentaire est construit et on comprends parfaitement que le tweet d'origine était un moyen pour AstronoGeek de mener une expérience sociale qui est partie totalement en cacahuète (en même temps Twitter c'est un petit peu la poubelle du net, je ne le blâme pas, il a été aussi malin que les gens dont il se moque à longueur de temps. Je vous ai dit que je n'aimais pas trop le personnage ? Bref).

Par contre, je ne peux m'empêcher de faire le lien avec ce post de HowTommy qui relaie un Tweet répertoriant justement les youtubeurs estampillés #BalanceTonYoutubers. Or AstronoGeek y figure à cause du "vrai-faux-post" qu'il a publié pour "trigger" les SJW et ainsi récupérer suffisamment de données pour mener son expérience sociale.

J'invite ceux qui me lisent à se méfier de plus en plus des reposts de tweets, sans commentaire ni analyse, qui pop sur nos rivers car cela les transforment en Twitter bis et met en avant l'émotionnel, le ressenti au détriment de la raison, la logique et les faits. Après ce n'est que mon humble avis.

En résumé, ne nous twitterisons pas. Un Shaarli est justement un outil parfait pour exprimer un point de vue complet, argumenté, construit et sans censure dont la décentralisation en fait un anti-Twitter par excellence. Reposter des tweets sans recule ni commentaire revient à utiliser Twitter tout en perdant son temps pour administrer l'instance de son Shaarli. Je n'en comprends pas vraiment la raison ni l'utilité. Avoir bonne conscience ? Se sentir différent tout en faisant comme les autres ?

Je ne dis pas que tous les tweets sont stupides et qu'il ne faudrait en reposter aucun, je dis que retweeter un tweet en le croyant sur simple publication, sans le commenter et depuis son Shaarli, revient à utiliser Twitter comme les Twittos (peut-être en se pensant différent mais en agissant pareil sur le fond) ; surtout lorsqu'il s'agit d'un thread purement basé sur le lynchage public de personnes dont nous ne connaissons pas la vraie vie et dont la seule motivation est la destruction totale de quelqu'un. Cette violence abjecte est la caractéristique d'un ressenti façonné à partir d'une morale d'esclave (cf. Nietzsche).

Dans tous les cas, les deux vidéos sont à écouter/voir.