Comme je le disais plus haut ça viole un principe de substitution (sans parler de Liskov) car le code appelant est conscient de l'ensemble du typage et donc que tu ne peu plus ajouter un sous type sans récrire le code qui utilise ton objet.
Je comprends que Liskov ne s'intéresse qu'à la modélisation et pas à comment ils sont utilisés, mais ici il s'agit de retirer les traits du type pour le mettre dans le code appelant. On peut effectivement dire que ça n'est pas un viol du principe de Liskov, mais c'est une manière de s'en passer. Dans des cas extrêmes, mais qui ne sont pas difficiles à trouver, tu n'a aucun trait dans le type parent.
Dans ton exemple la méthode foo doit pouvoir prendre en paramètre n’importe quel sous-type de A en respectant le contrat (sur A) de la méthode formatted, donc si formatted est implémentée correctement à mon avis on est bon pour le principe de substitution.
Si tu crée un nouveau sous type de A, ta fonction ne compile plus.
Le fais que du code utilisateur soit conscient des sous type de ses paramètres (ou de ce qu'il reçoit d'une fonction) empêche la substitution.
Mais tu veux ptete parler du principe d’encapsulation ?
On parle de typage et pas de l'état interne des objets donc je dirais que non.
Ce qui blesse le cœur de tout ceux qui expliqueraient (non sans raison) que le polymorphisme c'est bien et qu'il faudrait une méthode décrite dans A et implémentée dans B et C. Ici le fait qu'une méthode hors de A, B ou C, cherche à déterminer le type sous-jacent de la référence a est la violation la plus classique de Liskov.
Présenté autrement : en respectant Liskov si tu crée un sous-type du type T tu devrais pouvoir remplacer n'importe quelle référence de T par une instance de ton sous-type sans changement du code qui utilise la référence. Ce n'est évidement pas le cas ici et c'est même un effet recherché.
C'est pour ça qu'il faut manier avec précaution dans un langage comme java qui utilise surtout le polymorphisme de classe et qui commence tout juste à utiliser ce genre de mécanismes (tout le monde appel ça du pattern matching, mais ça n'en est pas en java).
[…] potentiellement au prix d'avoir atomise les autres transactions qui étaient potentiellement en cours dans le meme process (donc potentiellement, pas nul du tout).
En erlang les threads userlands sont appelés process (ouai je trouve pas que ce soit un super nommage) et je pense que ça de ça qu'il parlait donc ça ne devrait pas être aussi impactant.
Tu peux probablement trouver une variante de ce probleme qui ne se résoud pas en changeant l'énoncé de la question, mais dans ce cas ci, ca se résoud tres facilement.
Oui le nommage de ma fonction à l'arrache n'était pas génial et tu as mieux exprimé que moi ce que je voulais dire par le fait que c'est une question de sémantique.
Il me semble que l'on a un tropisme à ce sujet. La Chine et le Brésil font beaucoup de choses qu'on ne connaît pas trop. Et pour la Chine ils ont même leurs Big tech qui font du libre à la marge quand ça les arrange à la Google.
C'est le PDG qui a décidé de passer d'une licence open source qui a fait connaître son produit à une licence non open source car plus bankable une fois le produit connu et utilisé, car ça marche pour le moment plutôt pas mal comme méthode pour maximiser le business.
Ça n'est pas un rappel, c'est le sujet de l'article.
Pour ceux qui lisent plus les commentaires que les articles. Le PDG d'Hashicorp réagi au fait que la Linux Fondation héberge le fork sous licence MPL de Terraform qui est passé sous BUSL en août dernier. Évidement qu'il n'est pas content. La phrase mise en avant vient du fait qu'il dit qu'il n'est que l'une des entreprises qui ont fait ce mouvement et il croit que si le libre « n'évolue pas » tous les acteurs finiront par faire ce mouvement.
Je pense que la question peut tout de même être intéressante posée autrement :
Il existe un mouvement depuis quelques années de logiciel qui sortent du libre comme ça. D'où est-ce que ça vient et où est-ce que ça va aller ? Et peut être est-ce qu'il y a un moyen de l'endiguer et est-ce que c'est souhaitable ?
J’ai lu une fois qu’on pouvait toujours utiliser || ou && (avec les accolades qui vont bien si nécessaires) pour remplacer, de manière fort élégante je trouve aussi, l’utilisation d’un if (et des then et fi sans lequel il n’est rien qu’une erreur de syntaxe !). Il semblerait donc que ce soit toujours possible sauf dans le cas[…]
Pour moi c'est un peu comme si tu trouve un vert très joli et que du coup tu repeins TOUT ton logement dans cette couleur du sol au plafond, fenêtres et vaisselles inclue. Il y a des cas où c'est très élégant d'utiliser ce genre de construction, mais quand on l'utilise là où elle n'a pas particulièrement de sens voir qu'elle oblige à faire des circonvolutions ça devient moche.
Sinon en dehors de ça, pour ce qui est est des constructions programmatique contre-intuitives mais souvent pratiques et concises, il y a l’utilisation du mécanisme de gestion des exceptions pour implémenter la logique du programme, c’est manifestement une chose souvent bien vue, en Python notamment, bien que ce langage se présente comme le plus « évident », le moins piégeux. Le try() … catch … n’a pourtant pas été créé comme une construction usuelle à la base !
Non, c’est plus vaste que ça, ça permet en particulier d’écrire des chaines d’appels complètes sans avoir à gérer des null en plein milieu et de couper la logique fonctionnelle avec des batteries de if.
Ça n'est pas plus vaste, c'est un choix de vouloir continuer à avoir une API fluent un peut plus loin que les Stream. Je ne crois pas que le prix en vaille la chandelle. Avoir une API fluent ce n'est pas de la programmation fonctionnelle, ça vient à mon avis d'un mélange : la programmation fonctionnelle ne connaît que des expressions et pas d'instruction et éventuellement ils ont des monades quand ils ont besoin.
Note aussi que, dès aujourd’hui, tu peux aussi utiliser l’un des trop nombreux frameworks qui permettent de gérer les null avec des annotations @Nullable / @NonNull. C’est juste moins intégré au langage lui-même.
La JSR305 est sympa même si elle mériterait d'avoir un peu plus d'amour (de la part de ces concepteurs et des utilisateurs). Elle a l'avantage d'être utilisable dans bien plus de cas.
Bof si c'est pour findAny() et findFirst(), ils auraient pu retourner des valeur null comme le fait l'API de collection. Ça me parait moins pire que de se coltiner du code des décennies alors qu'on avait déjà planifié au moment de son écriture qu'elle allait être désuète. Le plus drôle c'est que vavr utilise déjà ce genre de design avec java 7…
Dans 2 ans on aura :
les fonctions qui retournent null
les fonctions qui retournent Optional
les fonctions qui retournent Neither ou un truc comme ça qui tirera profit de ce qu'on a actuellement
A quel point la notion est utile ou même obligatoire en informatique?
À moins que ça m'échappe je ne connais pas de langages de programmation commun1 qui ne l'implémentent pas il me semble. Mais il y a 2 manières de faire soit c'est une valeur qui est valide dans tous les types nullables (donc toute références en java, tout pointeur en C/C++, etc) soit c'est un type.
Quand c'est un type généralement le langage permet de créer des types sommes ce qui permet de créer un type « entier ou null » et ça t'oblige à vérifier que c'est un entier avant de pouvoir utiliser ta variable. Je trouve ça plus élégant personnellement.
Je ne classe pas Malbolge comme commun, ni les langages simulant une machine de Turing ↩
Ça m'embête supposé très doctrinal. Ça dépend complètement de la sémantique que tu donne. Si je compte la taille d'un message, je peux vouloir considérer que sa taille est nulle ou valant 0 qu'il s'agisse d'une chaîne vide, d'un champ absent ou d'un champ ayant pour valeur null ou undefine si c'est représenté par du json par exemple. Multiplier les chemins d'exécutions pour ça n'a pas de sens et planter pour relancer le processus est un bug : une valeur nulle n'est pas synonyme d'erreur.
Penser que les choses ont un sens intrinsèque et que ton modèle est universel est à mon avis une erreur pas lié au langage ou à la stack utilisée.
Tu peux vouloir éliminer les valeurs null en les représentants dans ton typage et c'est très bien, tu n'a plus à avoir ce genre de garde dans tes fonctions mais c'est pas une absence de programmation défensive, elle est déplacée aux entrées de ton programme. Mais ça ne me paraît pas pertinent si le langage ne permet pas de l'exprimer. Java ne le permet pas et il me semble qu'erlang non plus toute références peuvent être nil il me semble.
Mais sinon c'est une option à prendre en compte : ne rien faire et laisser l'exception arriver. Maintenant que les NullPointerException donnent (enfin !) des informations sur ce qui était null. Ça vaut le coup de laisser faire le langage naturellement.
Sealed c'est un moyen de contrôler l'héritage d'une classe ou d'une interface.
Jusqu'à l'arrivée de sealed on avait le mot clef final qui indiquait qu'une classe ne pouvait avoir de fille. sealed permet d'indiquer la liste exhaustive des filles direct d'une classe. Dans l'exemple au dessus, Optional<T> n'a que 2 soustype Present et Absent.
Ça peut être assez déroutant parce que ça contreviens au principe de substitution de Liskov, mais c'est pratique pour certaines choses. Ça ne doit pas être utilisé pour tout, mais pour des cas où on sait qu'on a un arbre de types limité qui ne devrait pas évoluer sans que le code qui l'utilise le prenne en compte.
Imaginons (je tire l'exemple de mon chapeau c'est peut être pas un bon exemple), tu veut gérer une machine à états finis, mais ça t'arrangerait que l'état soit plus qu'une simple valeur (donc pas un enum) par exemple pour aider au debug. Tu peut alors créer une classe ou une interface et dont tu sais que toutes les filles direct représente un état de ta machine.
L'intérêt c'est de pouvoir utiliser ça avec le pattern matching et les switch expressions, puisque tu va pouvoir manipuler ton état tout en garantissant l’exhaustivité des cas. Si tu ajoute un nouvel état c'est un nouveau sous-type et tu devra l'implémenter dans tout les endroits où tu a eu besoin de traiter tes états.
Une autre manière de voir c'est de s'en servir comme un type somme du pauvre. Tu peut créer un type T qui est soit A, soit B, soit C,… et écrire des fonctions qui sont polymorphiques sur leur paramètre (tu prend en paramètre un type T et en fonction du sous-type tu réagi différemment). Du pauvre parce que les sous-type ne peuvent pas être arbitraires comme tu le ferait en haskel.
Je n'ai jamais compris pourquoi ils ont implémenté Optional aussi tôt… Ils avaient déjà l'idée de ce qui allait se faire et aujourd'hui je trouve que c'est une classe qui utilise mal le langage. À mon avis Optional devrait être une interface sealed implémentée par un record disons Present et une classe (voir un singleton) Absent. Il ne devrait pas y avoir de méthode get() et l'interface ne devrait porter que le méthodes qui en font une monade. Tu aurais une classe dont aucune des méthodes ne peut lever de NPE et au lieu d'avoir tous les analyseurs statiques qui doivent tenter de vérifier si tu utilise get() dans un endroit sûr ce serait vérifié dans le langage par le typage (et pour le quel l'inlining peut rendre ton code efficace). Et tu n'aurait plus besoin de la méthode get() grâce au pattern matching (qui n'en est pas vraiment un en java). On va garder encore 20 ans une classe qui aura finalement rapidement était hors de ce que Java peut produire.
Pour moi aussi c'était une référence en non https, mais je pense plutôt que le domaine a était perdu et que DreamHost fais des redirections https dans ce genre de cas.
Je ne connais pas le cas d'AOSP, mais je suppose que l'idée, c'est de forcer les constructeurs à passer par Google pour avoir le code à l'heure dite.
Il n'y en a pas besoin. Ils ne peuvent pas vendre de téléphone avec les "services Google" (ou gapps). Ils n'ont même pas le droit de vendre des téléphones sous AOSP et sous Android d'après ce que j'avais lu de fairephone. Comme toutes les grosses boites, Google sait verrouiller sa clientèle.
Je trouve toujours embêtant d'utiliser billion qui peut vouloir dire 10⁹ ou 10¹² (selon comment celui qui l'utilise a une lecture anglo-saxonne). Du coup pour ma compréhension, c'est 60G€ ou 60T€ ?
Sauf qu'avec le logiciel libre, on crée un bien commun. Avec lequel tout le monde peut fournir un travail et se faire rémunérer pour, sans avoir à payer une taxe.
Je ne suis pas d'accord. Certains logiciels libres deviennent des communs, c'est à dire quelque chose qui vit par et pour une communauté. Mais la plupart restent au final uniquement des ressources gratuites, les gens sont très contents de les utiliser mais ne veulent pas entendre parler de coût et de comment faire vivre cette ressource.
Je ne me revendique pas libriste parce que je vois pleins de problèmes au mouvement et au communauté qui s'en réclame et que je pense sincèrement que c'est une grille de lecture qui doit évoluer. Il y a d'ailleurs un paragraphe dans mon précédent commentaire qui en est une approche
Je ne trouve pas que c'est négatif, je pense même que le partage est un devoir moral, je trouve juste pas que c'est anti concurrentiel
Tu ne souhaite parler qu'à des libristes ? D'une part ça a l'air d'une dérive sectaire, mais surtout je t'ai suffisamment vu faire des procès en non librisme pour que je sache que tu adore parler de manière non sérieuse pour troller sur qui sera le meilleur parangon du libre
C'est tuer la concurrence de ne pas laisser les concurrents se servir de ton travail ? Pourquoi pas, mais du coup je trouve tout de même qu'utiliser le même mot pour ça et les actions visant activement à tuer la concurrence (pèle mêle : les abus de position dominantes, les OPA plus ou moins hostiles, les procès pour consommer l'argent de ton concurrent, l'abus de position de plateforme, etc) est dommage.
Du coup si je crée, je sais pas disons un éditeur d'image qui produit des fichiers image.ploplo. Un format que je trouve cool et dont la spécification est mon implémentation et elle peut changer à chaque mise à jour, je le considère comme un détail d'implémentation comme le format de stockage de la plupart des bases de données. Bien sûr ce n'est pas implémenté comme une bibliothèque de mon logiciel. Est-ce que je tue la concurrence en mettant des batons dans les roues de mes concurrents pour qui il serait difficile voir impossible de réutiliser mon super format ?
De plus certains font ça sans toucher à la licence. Le code est libre et on te file les binaires que si tu paie par exemple.
Ils le feront peut-être le jour où ça ne sera plus bankable.
Non ils ne le feront jamais. C'est pas une question d'argent. Nintendo est parfaitement en dehors du libre. C'est hors de leur culture, de leur ADN, ils ne savent pas ce que c'est et n'ont rien à faire d'en apprendre plus. Ils n'en ont pas besoin et n'en n'auront probablement jamais besoin ou préfèreront laisser la boite mourir que de tenter cette bizarrerie. Aussi vrai que la gravité existe, ils ne s'embêteront jamais avec ça.
L'argent, tout est autour de l'argent.
Et de communication comme tu le disait dans ton premier commentaire. À moins que tu ramène tout à l'argent, mais c'est un peu triché. Je doute que Google retarde les sorties d'AOSP pour des questions d'argent. Aucun constructeurs ne se risquerait à sortir un téléphone AOSP qui soit financièrement significatif pour Google. C'est une question de contrôle et de moyens mis dans ce sens à mon avis.
c'est un peu la durée du support d'une version Android ou Debian en entier donc un peu beaucoup en comparaison (après, si on augmente la durée du support des exemples cités, ça m'irait aussi assez bien :) ).
Je doute qu'un DD soit contre de continuer à supporter Bo encore aujourd'hui par exemple, mais ça peut difficilement être un travail gratuit. Moi je trouve que c'est complètement con, mais c'est un autre débat.
Je ne dis pas que ça ne change rien, je dis que le fait de s’accommoder d'un délai c'est d'une part de s’accommoder d'un non libre (j'ai connu des gens reprocher à d'autres de ne pas aimer le libre pour ce genre de raison😉) et d'autre part que l'impact est dépendant du contexte et du point de vu de chacun. Si on prend AOSP par exemple, ce n'est pas une question de bankable, Google a des partenariat avec les constructeurs qui font qu'AOSP n'entre pas en concurrence financière avec Android. Et je suis certains que si Nintendo sortait aujourd'hui le code de The Legend of Zelda sorti il y a 37 ans et plus vendu (je crois qu'il est dispo en abonnement sur switch, mais avec des dizaines d'autres jeux) il y aurait du monde de content.
[^] # Re: sealed ?
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 3.
Comme je le disais plus haut ça viole un principe de substitution (sans parler de Liskov) car le code appelant est conscient de l'ensemble du typage et donc que tu ne peu plus ajouter un sous type sans récrire le code qui utilise ton objet.
Je comprends que Liskov ne s'intéresse qu'à la modélisation et pas à comment ils sont utilisés, mais ici il s'agit de retirer les traits du type pour le mettre dans le code appelant. On peut effectivement dire que ça n'est pas un viol du principe de Liskov, mais c'est une manière de s'en passer. Dans des cas extrêmes, mais qui ne sont pas difficiles à trouver, tu n'a aucun trait dans le type parent.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: sealed ?
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 5.
Si tu crée un nouveau sous type de A, ta fonction ne compile plus.
Le fais que du code utilisateur soit conscient des sous type de ses paramètres (ou de ce qu'il reçoit d'une fonction) empêche la substitution.
On parle de typage et pas de l'état interne des objets donc je dirais que non.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: sealed ?
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 3.
La classe mère qui liste ses classes filles d'une part et parce que c'est globalement fait pour écrire :
Ce qui blesse le cœur de tout ceux qui expliqueraient (non sans raison) que le polymorphisme c'est bien et qu'il faudrait une méthode décrite dans A et implémentée dans B et C. Ici le fait qu'une méthode hors de A, B ou C, cherche à déterminer le type sous-jacent de la référence a est la violation la plus classique de Liskov.
Présenté autrement : en respectant Liskov si tu crée un sous-type du type T tu devrais pouvoir remplacer n'importe quelle référence de T par une instance de ton sous-type sans changement du code qui utilise la référence. Ce n'est évidement pas le cas ici et c'est même un effet recherché.
C'est pour ça qu'il faut manier avec précaution dans un langage comme java qui utilise surtout le polymorphisme de classe et qui commence tout juste à utiliser ce genre de mécanismes (tout le monde appel ça du pattern matching, mais ça n'en est pas en java).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: et ses serveurs ?
Posté par barmic 🦦 . En réponse au lien Le PDG d'HashiCorp prédit "une Silicon Valley sans logiciel libre". Évalué à 2.
Le sens de la phrase c'est : les entreprises de la Silicone Valley ne feront plus de LL pas n'en utiliseront plus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: j'ai du mal à comprendre un truc ....
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 3.
En erlang les threads userlands sont appelés process (ouai je trouve pas que ce soit un super nommage) et je pense que ça de ça qu'il parlait donc ça ne devrait pas être aussi impactant.
Oui le nommage de ma fonction à l'arrache n'était pas génial et tu as mieux exprimé que moi ce que je voulais dire par le fait que c'est une question de sémantique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: et l'inverse ?
Posté par barmic 🦦 . En réponse au lien Le PDG d'HashiCorp prédit "une Silicon Valley sans logiciel libre". Évalué à 3.
Il me semble que l'on a un tropisme à ce sujet. La Chine et le Brésil font beaucoup de choses qu'on ne connaît pas trop. Et pour la Chine ils ont même leurs Big tech qui font du libre à la marge quand ça les arrange à la Google.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Rappel
Posté par barmic 🦦 . En réponse au lien Le PDG d'HashiCorp prédit "une Silicon Valley sans logiciel libre". Évalué à 6.
Ça n'est pas un rappel, c'est le sujet de l'article.
Pour ceux qui lisent plus les commentaires que les articles. Le PDG d'Hashicorp réagi au fait que la Linux Fondation héberge le fork sous licence MPL de Terraform qui est passé sous BUSL en août dernier. Évidement qu'il n'est pas content. La phrase mise en avant vient du fait qu'il dit qu'il n'est que l'une des entreprises qui ont fait ce mouvement et il croit que si le libre « n'évolue pas » tous les acteurs finiront par faire ce mouvement.
Je pense que la question peut tout de même être intéressante posée autrement :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Shell
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 5.
J'ai mis trop de temps pour éditer mon message
Pour moi c'est un peu comme si tu trouve un vert très joli et que du coup tu repeins TOUT ton logement dans cette couleur du sol au plafond, fenêtres et vaisselles inclue. Il y a des cas où c'est très élégant d'utiliser ce genre de construction, mais quand on l'utilise là où elle n'a pas particulièrement de sens voir qu'elle oblige à faire des circonvolutions ça devient moche.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Shell
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 2.
J'ai pas compris ce que tu voulais dire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Optional<T>
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 3.
Ça n'est pas plus vaste, c'est un choix de vouloir continuer à avoir une API fluent un peut plus loin que les Stream. Je ne crois pas que le prix en vaille la chandelle. Avoir une API fluent ce n'est pas de la programmation fonctionnelle, ça vient à mon avis d'un mélange : la programmation fonctionnelle ne connaît que des expressions et pas d'instruction et éventuellement ils ont des monades quand ils ont besoin.
La JSR305 est sympa même si elle mériterait d'avoir un peu plus d'amour (de la part de ces concepteurs et des utilisateurs). Elle a l'avantage d'être utilisable dans bien plus de cas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Optional<T>
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 3.
Bof si c'est pour
findAny()etfindFirst(), ils auraient pu retourner des valeurnullcomme le fait l'API de collection. Ça me parait moins pire que de se coltiner du code des décennies alors qu'on avait déjà planifié au moment de son écriture qu'elle allait être désuète. Le plus drôle c'est que vavr utilise déjà ce genre de design avec java 7…Dans 2 ans on aura :
Ouai !…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: j'ai du mal à comprendre un truc ....
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 4.
À moins que ça m'échappe je ne connais pas de langages de programmation commun1 qui ne l'implémentent pas il me semble. Mais il y a 2 manières de faire soit c'est une valeur qui est valide dans tous les types nullables (donc toute références en java, tout pointeur en C/C++, etc) soit c'est un type.
Quand c'est un type généralement le langage permet de créer des types sommes ce qui permet de créer un type « entier ou null » et ça t'oblige à vérifier que c'est un entier avant de pouvoir utiliser ta variable. Je trouve ça plus élégant personnellement.
Je ne classe pas Malbolge comme commun, ni les langages simulant une machine de Turing ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: j'ai du mal à comprendre un truc ....
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 4.
Null n'est pas un type en java.
Ça m'embête supposé très doctrinal. Ça dépend complètement de la sémantique que tu donne. Si je compte la taille d'un message, je peux vouloir considérer que sa taille est nulle ou valant 0 qu'il s'agisse d'une chaîne vide, d'un champ absent ou d'un champ ayant pour valeur null ou undefine si c'est représenté par du json par exemple. Multiplier les chemins d'exécutions pour ça n'a pas de sens et planter pour relancer le processus est un bug : une valeur nulle n'est pas synonyme d'erreur.
Penser que les choses ont un sens intrinsèque et que ton modèle est universel est à mon avis une erreur pas lié au langage ou à la stack utilisée.
Tu peux vouloir éliminer les valeurs null en les représentants dans ton typage et c'est très bien, tu n'a plus à avoir ce genre de garde dans tes fonctions mais c'est pas une absence de programmation défensive, elle est déplacée aux entrées de ton programme. Mais ça ne me paraît pas pertinent si le langage ne permet pas de l'exprimer. Java ne le permet pas et il me semble qu'erlang non plus toute références peuvent être
nilil me semble.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: j'ai du mal à comprendre un truc ....
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 5.
Ça n'est pas forcément un cas exceptionnel.
Tu peux vouloir écrire :
Mais sinon c'est une option à prendre en compte : ne rien faire et laisser l'exception arriver. Maintenant que les
NullPointerExceptiondonnent (enfin !) des informations sur ce qui étaitnull. Ça vaut le coup de laisser faire le langage naturellement.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: sealed ?
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 6.
Sealed c'est un moyen de contrôler l'héritage d'une classe ou d'une interface.
Jusqu'à l'arrivée de
sealedon avait le mot cleffinalqui indiquait qu'une classe ne pouvait avoir de fille.sealedpermet d'indiquer la liste exhaustive des filles direct d'une classe. Dans l'exemple au dessus,Optional<T>n'a que 2 soustypePresentetAbsent.Ça peut être assez déroutant parce que ça contreviens au principe de substitution de Liskov, mais c'est pratique pour certaines choses. Ça ne doit pas être utilisé pour tout, mais pour des cas où on sait qu'on a un arbre de types limité qui ne devrait pas évoluer sans que le code qui l'utilise le prenne en compte.
Imaginons (je tire l'exemple de mon chapeau c'est peut être pas un bon exemple), tu veut gérer une machine à états finis, mais ça t'arrangerait que l'état soit plus qu'une simple valeur (donc pas un enum) par exemple pour aider au debug. Tu peut alors créer une classe ou une interface et dont tu sais que toutes les filles direct représente un état de ta machine.
L'intérêt c'est de pouvoir utiliser ça avec le pattern matching et les switch expressions, puisque tu va pouvoir manipuler ton état tout en garantissant l’exhaustivité des cas. Si tu ajoute un nouvel état c'est un nouveau sous-type et tu devra l'implémenter dans tout les endroits où tu a eu besoin de traiter tes états.
Une autre manière de voir c'est de s'en servir comme un type somme du pauvre. Tu peut créer un type T qui est soit A, soit B, soit C,… et écrire des fonctions qui sont polymorphiques sur leur paramètre (tu prend en paramètre un type T et en fonction du sous-type tu réagi différemment). Du pauvre parce que les sous-type ne peuvent pas être arbitraires comme tu le ferait en haskel.
Je suis un peu loquace ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Shell
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 7.
J'aime beaucoup perl pour ça :
et je le reproduit en shell quand le cas se présente en écrivant ma propre méthode
die()https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Optional<T>
Posté par barmic 🦦 . En réponse au journal La plus belle ligne de code. Évalué à 4.
Je n'ai jamais compris pourquoi ils ont implémenté Optional aussi tôt… Ils avaient déjà l'idée de ce qui allait se faire et aujourd'hui je trouve que c'est une classe qui utilise mal le langage. À mon avis Optional devrait être une interface sealed implémentée par un record disons Present et une classe (voir un singleton) Absent. Il ne devrait pas y avoir de méthode get() et l'interface ne devrait porter que le méthodes qui en font une monade. Tu aurais une classe dont aucune des méthodes ne peut lever de NPE et au lieu d'avoir tous les analyseurs statiques qui doivent tenter de vérifier si tu utilise get() dans un endroit sûr ce serait vérifié dans le langage par le typage (et pour le quel l'inlining peut rendre ton code efficace). Et tu n'aurait plus besoin de la méthode get() grâce au pattern matching (qui n'en est pas vraiment un en java). On va garder encore 20 ans une classe qui aura finalement rapidement était hors de ce que Java peut produire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: https ?
Posté par barmic 🦦 . En réponse au lien Perdu.com est mort. Évalué à 6.
Pour moi aussi c'était une référence en non https, mais je pense plutôt que le domaine a était perdu et que DreamHost fais des redirections https dans ce genre de cas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Taxe sur les transactions financières
Posté par barmic 🦦 . En réponse au lien Hôpital-Le gouvernement veut encore gratter 600 millions (et surtt, on applaudit bien sur le balcon). Évalué à 2.
Tu compte l'argent en mille romain ? :p
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tout est dans les détails
Posté par barmic 🦦 . En réponse au lien Arangodb veut passer son code sous BUSL 1. Évalué à 3.
Il n'y en a pas besoin. Ils ne peuvent pas vendre de téléphone avec les "services Google" (ou gapps). Ils n'ont même pas le droit de vendre des téléphones sous AOSP et sous Android d'après ce que j'avais lu de fairephone. Comme toutes les grosses boites, Google sait verrouiller sa clientèle.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Taxe sur les transactions financières
Posté par barmic 🦦 . En réponse au lien Hôpital-Le gouvernement veut encore gratter 600 millions (et surtt, on applaudit bien sur le balcon). Évalué à 7.
Je trouve toujours embêtant d'utiliser billion qui peut vouloir dire 10⁹ ou 10¹² (selon comment celui qui l'utilise a une lecture anglo-saxonne). Du coup pour ma compréhension, c'est 60G€ ou 60T€ ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tout est dans les détails
Posté par barmic 🦦 . En réponse au lien Arangodb veut passer son code sous BUSL 1. Évalué à 1.
Je ne suis pas d'accord. Certains logiciels libres deviennent des communs, c'est à dire quelque chose qui vit par et pour une communauté. Mais la plupart restent au final uniquement des ressources gratuites, les gens sont très contents de les utiliser mais ne veulent pas entendre parler de coût et de comment faire vivre cette ressource.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tout est dans les détails
Posté par barmic 🦦 . En réponse au lien Arangodb veut passer son code sous BUSL 1. Évalué à 1.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tout est dans les détails
Posté par barmic 🦦 . En réponse au lien Arangodb veut passer son code sous BUSL 1. Évalué à 1. Dernière modification le 12 octobre 2023 à 23:23.
C'est tuer la concurrence de ne pas laisser les concurrents se servir de ton travail ? Pourquoi pas, mais du coup je trouve tout de même qu'utiliser le même mot pour ça et les actions visant activement à tuer la concurrence (pèle mêle : les abus de position dominantes, les OPA plus ou moins hostiles, les procès pour consommer l'argent de ton concurrent, l'abus de position de plateforme, etc) est dommage.
Du coup si je crée, je sais pas disons un éditeur d'image qui produit des fichiers
image.ploplo. Un format que je trouve cool et dont la spécification est mon implémentation et elle peut changer à chaque mise à jour, je le considère comme un détail d'implémentation comme le format de stockage de la plupart des bases de données. Bien sûr ce n'est pas implémenté comme une bibliothèque de mon logiciel. Est-ce que je tue la concurrence en mettant des batons dans les roues de mes concurrents pour qui il serait difficile voir impossible de réutiliser mon super format ?De plus certains font ça sans toucher à la licence. Le code est libre et on te file les binaires que si tu paie par exemple.
Non ils ne le feront jamais. C'est pas une question d'argent. Nintendo est parfaitement en dehors du libre. C'est hors de leur culture, de leur ADN, ils ne savent pas ce que c'est et n'ont rien à faire d'en apprendre plus. Ils n'en ont pas besoin et n'en n'auront probablement jamais besoin ou préfèreront laisser la boite mourir que de tenter cette bizarrerie. Aussi vrai que la gravité existe, ils ne s'embêteront jamais avec ça.
Et de communication comme tu le disait dans ton premier commentaire. À moins que tu ramène tout à l'argent, mais c'est un peu triché. Je doute que Google retarde les sorties d'AOSP pour des questions d'argent. Aucun constructeurs ne se risquerait à sortir un téléphone AOSP qui soit financièrement significatif pour Google. C'est une question de contrôle et de moyens mis dans ce sens à mon avis.
Je doute qu'un DD soit contre de continuer à supporter Bo encore aujourd'hui par exemple, mais ça peut difficilement être un travail gratuit. Moi je trouve que c'est complètement con, mais c'est un autre débat.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Tout est dans les détails
Posté par barmic 🦦 . En réponse au lien Arangodb veut passer son code sous BUSL 1. Évalué à 2.
Je ne dis pas que ça ne change rien, je dis que le fait de s’accommoder d'un délai c'est d'une part de s’accommoder d'un non libre (j'ai connu des gens reprocher à d'autres de ne pas aimer le libre pour ce genre de raison😉) et d'autre part que l'impact est dépendant du contexte et du point de vu de chacun. Si on prend AOSP par exemple, ce n'est pas une question de bankable, Google a des partenariat avec les constructeurs qui font qu'AOSP n'entre pas en concurrence financière avec Android. Et je suis certains que si Nintendo sortait aujourd'hui le code de The Legend of Zelda sorti il y a 37 ans et plus vendu (je crois qu'il est dispo en abonnement sur switch, mais avec des dizaines d'autres jeux) il y aurait du monde de content.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll