Axioplase ıɥs∀ a écrit 3050 commentaires

Ca n'a pas de sens. Si je dois calculer la moyenne sur une liste qui ne contient pas que des nombres, alors soit j'ai mal designé mon architecture, soit je fais

interface MyStuff {
  public Optional<Integer> toInt();
}

Et le reste devient

int result = 0;
for (MyStuff stuff : mystuff) {
    result += stuff.toInt().orElse(0);
  }
}

C'est propre et facile à comprendre.

Ma solution marche pour tous: Set, ArrayList, LinkedList, HashMap, etc. (Interface ou pas, les génériques acceptent mon type).
La tienne a réinventé la roue pour la liste. Si demain il veux utiliser une autre collection, il n'a pas de solution avec ta librairie.

Bref, Object, c'est mal, l'héritage (?) et l'Open-Closed, c'est bien.

Si le contexte est connu et n'est pas exposé par l'API, alors tu peux faire

final Class AouB {
private Type typ;
private final Optional<A> a;
private final Optional<B> B;
private print() {
switch (typ):
case Type.A: a.print(); break;
case Type.B: b.print(); break;
}
}

Et utiliser des sous classes ou une factory pour créer des objets de type AouB, mais ça n'est pas extensible par un utilisateur.

Au final, le truc, c'est qu'en Python, tu peux mettre n'importe quoi dans ta liste, et au final, tu peux avoir des erreurs de type à l'execution. En Java, il faut faire exprès pour se donner se problème, et c'est probablement une bonne idée de ne pas programmer ainsi. Tant pis si Python est plus facile et court à écrire.

Non seulement tu as des casts et des instanceOf, ce qui rend le code fragile, mais en plus l'utilisateur n'a plus de liste. Et comment tu ferais pour un Set? un ArrayList? un LinkedList? une HashMap? Tu vois pas un problème quelque part avec ta solution ?

C'est pas ce que je veux dire par « extensible ». Ton code n'est pas utilisable par quelqu'un qui utilise ta librairie et souhaite aussi mettre des caractères, des flottants, des voitures, ou des éléphants dans la liste. Ta liste est restreinte aux entiers et chaînes par définition.

Elle est pas exensible.

Que va retourner un objet EntierOuChaine si il a une méthode disons getValue ? Bin un Objet.

Si tu as besoin de coder Object getValue(), alors tu as un problème de design orienté objet.

Les développeurs de Perl ont donc décidé de se débarrasser de ce « fardeau » [de quel fardeau parlent‑ils ?] et d’activer un bon nombre de ces « défauts » qui sont quasi‑incontestables.

Il semblerait qu'un commentaire datant de l'ébauche de la nouvelle se soit retrouvé publié :)

Sinon, c'est interessant. Je ne savais pas que « Perl 6 n'était plus Perl » donc j'irai y jeter un œil aussi.

J'aurais pas été contre un petite liste des fonctionnalités activées de base aussi. use strict et tout.

Alors, "concis", c'est pas la bonne métrique. Si t'as envie de jouer au golfe, tant mieux. Mais je n'ai aucune envie de maintenir du code qui préfère la concision (et les potentiels bugs à l'execution) simplement car c'est concis. Tu veux un containeur qui contient tes objets spécifiques, et rien d'autre, mais qui soit extensible sans aucun changement.

import java.util.ArrayList;
import java.util.List;

class ListeExtensible {

    interface MyStuff { 
        public void print();
    }

    class MyInt implements MyStuff {
        final int i;
        public MyInt(int i) {
            this.i = i;
        }
        public void print() {
            System.out.println(this.i);
        }
    }

    class MyString implements MyStuff {
        final String s;
        public MyString(String s) {
            this.s = s;
        }
        public void print() {
            System.out.println(this.s);
        }
    }

    public void doStuff() {
        List<MyStuff> maListe = new ArrayList<>();
        maListe.add(new MyInt(1));
        maListe.add(new MyString("hello"));
        for (MyStuff element : maListe) {
            element.print();
        }
    }

    public static void main(String[] args) {
        ListeExtensible l = new ListeExtensible();
        l.doStuff();
    }
}

Pas besoin de casts (vu qu'on ne retourne jamais "Object"), on ne peut pas avoir d'erreur à l'exécution, et on peut ajouter autant de nouveau sous-types qu'on veut sans qu'on doive modifier aucun code existant. C'est, je crois, la manière de s'y prendre en Java. Alors, oui, c'est plus compliqué que Python, mais c'est ainsi. Language différent, paradigme différent.

Comment les generics permettent-ils de mettre deux types qui n'ont pas de relation de sous-typage dans la liste (ce que l'OP cherche à faire), sans passer par Object (qui est objectivement une mauvaise approche en termes de design/architecture Java) ou un nouveau type ? Je ne vois pas le rapport, et mon exemple utilise des génériques (List<Integer> par exemple). Si tu pas un passage précis dans les 20+ pages de ton lien qui indique comment mettre des entiers et des chaînes dans une liste, n'hésite pas à le partager.

S'il veut commencer par des choses plus douces, alors résoudre des exos Python en Java n'est pas une bonne idée. Python et Java sont très différents, et ce qui est élégant et simple dans l'un ne l'est pas forcément dans l'autre…

"Comment mélange-t-on des entiers et des chaînes dans une liste en Java ?" -> On ne le fait pas, ou alors on créée une liste d'objets "EntierOuChaîne". C'est à la fois plus dur, et la manière la plus simple.

Ah, non, ça c'est parce que le dernier project que j'ai écrit était en Python, où justement les types sont 'str' et 'int', donc je tape ça automatiquement…

Mais la syntaxe, on s'en cogne. Ton compilateur/IDE s'en charge pour toi. En revanche, utiliser Object au lieu d'un conteneur adéquat (ou d'une conversion vers une chaîne si c'est juste pour faire un affichage), c'est un problème d'un tout autre ordre…

Nan, mais faut pas abuser. Le langage est typé et objet, donc c'est beaucoup mieux d'utiliser une classe qui peut contenir n'importe lequel des deux type, plutôt qu'Object. Traduire Python en Java, c'est idiot. Autant apprendre à penser en Java : tu veux stocker deux types, tu crées un conteneur, et tu fais du Open/Close au lieu de faire des casts et des IFs…

En java, tu ferais qqchose comme ça:

List maListeDeNombres<Int> = new ArrayList<>();
maListeDeNombres.add(1);

List maListeDeChaines<Str> = new ArrayList<>();
maListeDeChaines.add("lundi");
...

Mais tu ne peux pas mettre 1 et "lundi" dans une même troisième liste. Tes choix sont:
* convertir les nombres en chaînes de caractères
* créer une classe NombreOuChaine qui peut contenir un nombre ou une chaîne, et créer List<NombreOuChaine> t3.

Oui, c'est un peu lourd. Mais ça évite pas mal de bugs que tu pourrais avoir en Python sur des projets plus larges, ou évite que tu regardes le type à l'exécution.

On devrait avoir des conditionnels, pas des futurs !
- je le referais
- je le referais faire
- je ne le referais pas
- je le referais autrement
- je demanderais pour qu'on le refasse ensemble

Et puis, c'est ptêt parce que ça fait plus d'une décade que je suis en dehors de la francophonie, mais "je demanderais POUR qu'on le refasse ensemble", ça m'écorche les nyeux et les noreilles…

Et enfin, je suis vieux jeu ; je propose même qu'on écrive « je demanderais qu'on le refît ensemble. »

Moi je me suis demandé s'il était gaucher ou pas: la tablature me parait à l'envers…

J'ai cliqué le lien du journal, même pas cherché dans mon moteur de recherche… Y'a rien dans le journal qui disait que c'était dispo en kit.

L'Ergodox que l'OP mentionne a un prix comparable.
Je n'ai pas vraiment eu de soucis avec la taille du clavier.

L'Ergodox a un prix comparable au Kinesis, dans les 350 USD. C'est tout aussi "hors de prix", et, en ce qui me concerne tout-à-fait acceptable. J'ai mon premier Kinesis depuis 2007, soit 1.6 dollars par mois. Un investissement bien rentable pour des raisons médicales.

Une fois que j'ai cité ces deux là il ne reste plus grand chose de potable en clavier avec les touches alignés … à si : l'émulateur de clavier d'android aligne les touches !

Tu oublies le parent de ces deux claviers: le Kinesis Advantage.
Je n'utilise que ça depuis 2007, et je suis en bépo (légèrement modifié à la main), mais ils font déjà ce genre de clavier depuis au moins les années 90.

Et tu as, encore plus ancien je crois, les claviers de chez maltron, y compris les claviers ergo à une main et pour personnes ne pouvant pas utiliser leurs mains.

Quand je vois les difficultés qu'on a à gérer des logiciels simples, je trouve le titre de ton journal un peu poussé ; une centrale, c'est pas un système simple…

Aussi, j'imagine qu'ils ont des procédés en place pour faire des post-mortem et corriger cette classe de problèmes en entier (et pas juste ce robinet).

Sur android, tu peux utiliser PasswdSafe comme client. Ils utilisent le même format, et il peut se synchroniser avec Dropbox (et potentiellement d'autres services?)

1. Design aussi simple que possible, mais qui rend facile le passage a` l'echelle.
2. Couverture des tests aussi haute que possible / aussi basse que justifiable (e.g., pas la peine de tester le code Java genere' par Lombok.)
3. Documentation decrivant le systeme tel qu'il est a` tout moment.
4. Respect des regles de Clean Code.
5. Facilite' pour toute personne nouvelle sur ce projet a` le modifier en respect les 4 points precedents.

Mais c'etait mon choix et j'etais content.

Il y a énormément de traductions littérales au Québec. On s'y fait.

La programmation fonctionnelle considère un programme de calcul comme l'évaluation de fonctions mathématiques basées sur le calcul lambda. Le calcul lambda est un système formel en logique mathématique pour exprimer le calcul basé sur l'abstraction de fonction et l'application utilisant la liaison et la substitution de variables. Il suit l'approche de la "solution à apporter", c'est-à-dire qu'il exprime la logique sans décrire son flux de contrôle, d'où il est aussi classé dans le paradigme de programmation déclarative.

J'ai pas souvenir d'avoir entendu "calcul lambda". Même la page Wikipedia liée dit "Lambda calcul".
Aussi, je ne pense pas que ça utilise nécessairement la substitution de variables, si on utilise la notation de Bruijn, spécifiquement vu qu'on manipule tous les termes d'une classe d'alpha-equivalence via une représentation canonique.