J'avais prévenu que je n'y connaissais pas grand chose en Java !
[...]
je préviens d'avance, je ne m'y connais pas plus en PHP qu'en Java).
Mais si tu n'y connais rien, pourquoi tu te tapes les bindings toi-même ? Tu sais que tu vas avoir des versions toutes bancales qui feront peur plus qu'elles donneront envie. Si tu as une lib libre de qualité en C++, tu ne devrais avoir aucun mal à convaincre des développeurs plus expérimentés de faire les bindings dans les langages qui les intéressent.
Oui mais, aussi bancal que ce soit, c'est toujours plus facile que d'avoir à partir de zéro. En outre, aussi expérimenté que soit le développeur, je doute qu'il y en ai beaucoup qui sachent interfacer du PHP avec du C++, mais je me trompe peut-être...
Ceci dit, pour le coup, j'ai peut-être une connaissance faisant du PHP qui pourra m'aider...
Pour le reste, dans l'ordre :
Tu ne mets pas 2 classes de premier niveau dans le même fichier en Java. C'est techniquement possible, mais personne ne fait ça.
Soit.
Il n'y a pratiquement aucune raison de faire new String() en Java. En fait, je n'en vois aucune.
En fait, si je comprend bien en faisant [String] tata = "tutu;", le new est fait automatiquement, c'est cela ?
Il n'y a aucun problème à utiliser un champ dans une méthode.
Dans tous les cas, une variable locale ne devrait jamais avoir le même nom qu'un champ – j'imagine que c'est la même chose en C++ ?
Franchement, je ne vois pas le problème, mais bon...
L'itérateur, c'est Java 5 (2004).
OK, je n'aurais donc aucun scrupule à l'utiliser.
Aucun intérêt à faire du Java < 8 en 2018 sur un nouveau projet.
OK.
On ne commite pas les if de test, ou alors on les commente – j'imagine que c'est la même chose en C++ ?
OK ! Pas taper ! Je vais mettre un commentaire !
Tu as bien compris pour le new.
Super !
Un code de démo doit être le plus clair possible et illustrer les bonnes pratiques. Si c'est plus clair avec 15 fichiers qu'avec un seul, alors ça doit être dans 15 fichiers – j'imagine que c'est la même chose en C++ ?
Sauf qu'en C++, le compilateur n'impose jamais une correspondance entre le nom d'un fichier et son contenu, donc on est plus facilement tenté de d'accumuler les classes dans un seul et même fichier (je ne dis pas que c'est une bonne chose !)
On ne peut pas « nuller » un type primitif, mais il y a les classes enveloppes (pour toi Integer) pour ça. Depuis Java 5 (2004) le boxing et l'unboxing (conversion classes enveloppes ↔ types primitifs) sont automatiques.
Je connaissais les Integer, je les utilise dans certains contextes, mais là il me semblait plus pertinent d'utiliser un int, pensant, sans doute à tord, que c'est plus léger qu'un Integer.
Le code que j'ai proposé pour le paramètre xml fonctionne normalement depuis Java 1.0.
Et je vais l'adopter.
Ton explication sur les triples négations n'enlève rien au fait que c'est une triple négation. Pour des raisons de lisibilité (et sauf cas très exceptionnel), un if/else à branches équilibrées (ici c'est le cas) devrait être de la forme if (a == b) { X() } else { Y() } et non if (a != b) { Y() } else { X() }. Et les actions devraient avoir un sens positif (ShowBidule) et pas négatif (HideBidule). C'est valable dans tous les langages, dont le C++.
L'une comme l'autre forme me convienne parfaitement, mais si ça peut faciliter la lecture à certains...
Par contre, le ShowBidule/HideBidule, faut voir, car ce sont des identifiant d'éléments de style, et ça risque de les alourdir.
Un code qui n'est pas un pur test devrait utiliser un logger (y'en a un dans l'API standard).
S'il n'y a effectivement rien à installer de plus, je vais probablement l'utiliser.
Un lien clé-valeur en Java, c'est une Map...
OK. Je vais voir ça.
J'ai essayé de le tester. J'ai eu le même genre d'emmerdes que barmic dans ce commentaire, sauf que moi j'ai écris mon retour sur ma pause au boulot. Je n'avais pas 1h à passer pour faire marcher le bordel.
Et tu as lancé le bordel dans un environnement sans interface graphique ? Je subodore que c'est ce qui est arrivé à barmic, mais je n'en ai pas la confirmation...
En tout cas merci pour tes retours...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: ... et pas qu'un ...
Posté par Claude SIMON (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 1.
Oui mais, aussi bancal que ce soit, c'est toujours plus facile que d'avoir à partir de zéro. En outre, aussi expérimenté que soit le développeur, je doute qu'il y en ai beaucoup qui sachent interfacer du PHP avec du C++, mais je me trompe peut-être...
Ceci dit, pour le coup, j'ai peut-être une connaissance faisant du PHP qui pourra m'aider...
Soit.
En fait, si je comprend bien en faisant
[String] tata = "tutu;", lenewest fait automatiquement, c'est cela ?Franchement, je ne vois pas le problème, mais bon...
OK, je n'aurais donc aucun scrupule à l'utiliser.
OK.
OK ! Pas taper ! Je vais mettre un commentaire !
Super !
Sauf qu'en C++, le compilateur n'impose jamais une correspondance entre le nom d'un fichier et son contenu, donc on est plus facilement tenté de d'accumuler les classes dans un seul et même fichier (je ne dis pas que c'est une bonne chose !)
Je connaissais les Integer, je les utilise dans certains contextes, mais là il me semblait plus pertinent d'utiliser un
int, pensant, sans doute à tord, que c'est plus léger qu'unInteger.Et je vais l'adopter.
L'une comme l'autre forme me convienne parfaitement, mais si ça peut faciliter la lecture à certains...
Par contre, le ShowBidule/HideBidule, faut voir, car ce sont des identifiant d'éléments de style, et ça risque de les alourdir.
S'il n'y a effectivement rien à installer de plus, je vais probablement l'utiliser.
OK. Je vais voir ça.
Et tu as lancé le bordel dans un environnement sans interface graphique ? Je subodore que c'est ce qui est arrivé à barmic, mais je n'en ai pas la confirmation...
En tout cas merci pour tes retours...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...