Reprise du message précédent :
vous savez s'il y a moyen d'intercepter les accès en écriture à un champ en java ? avec CGLIB par exemple ?
 
l'idée c'est que j'ai une classe avec une tonne de champs qui est remplie par un formulaire, donc j'aimerai dégager les getters et setters pour gagner des lignes.
 
Comme je suis en swing, j'ai besoin d'observateur sur les champs pour le MVC. Pour pas trop me faire chier, j'ai fait un proxy et j'intercepte les setter pour balourder les évènements de propertychange.
 
J'aimerai passer une vitesse supérieure et dégager les getters et setters, mais j'ai quand même besoin d'envoyer les events. D'où ma question.

tu écris tout a la main, et quand l'appli est finie (pas avant) tu penses ptet a generer le bordel.

Avec ASM c'est assez simple, t'as un classreader que tu branche à un classwriter avec le premier tu visite le code, avec un visiteur qui écrit dans le writer, sauf que t'override la visite de PUTFIELD pour mettre ton handler autour. Après t'as plus qu'à charger ce qui sort du writer comme une classe, tadam \o/
[edit]
Ah mais chuis con, j'ai vu les participants à l'envers je crois, ça va pas le faire en fait /o\

vu qu'il n'y a aucune définition claire de "finie", c'est fuck.
 
Je commence à générer quand j'en ai marre de tout le temps écrire le même code.

ben ouais mais fait ça au lieu de sur-engineerer à coup d'asm/proxys avant d'avoir un truc qui marche de a à z ? si y'a 40 attributs a copy paster spa la mort quoi ..

y'en a 90 et là j'en suis à une quinzaine et c'est déjà le merdier.
et j'ai des PDF qui se génère de A à Z

juste pour faire chier moinsmoins :  

parfois je me demande pourquoi

ne pourrait pas renvoyer tout simplement null plutot que péter ?
potentiellement ça peut devenir plus dur à débuguer, mais bon ...

je sens que nraynaud va nous sortir son traité sur le langage objet en quarante tomes

ça s'appelle prolonger une fonction : prévoir une valeur de sortie là où normalement il n'en existe pas.
Parfois c'est naturel, comme dans ton cas, mais parfois pas du tout.
Les exemples les plus chiants nous viennent du collège : la racine carrée ou log d'un nombre négatif, 0/0 (hum celui-ci il est spécial en fait),  etc. Là, il n'y a pas de prolongement naturel. Et pas de bonne solution artificielle non plus. Pareil pour la tête d'une liste vide.
 
Donc comme on sait pas résoudre tous les cas, on s'abstient partout (c'est pas vrai y'a qu'à voir Map.get(), mais c'est une lib, pas le core), y compris quand on saurait faire.
 
pour avoir bossé une fois avec un langage qui se voulait "sans erreurs" (donc tout était prolongé) ça ne résout rien en fait, c'est une fausse bonne idée au quotidien. La vie est irrégulière, et nos outils font avec.

je pensais aussi à la division par zéro, mais d'un autre côté on la multiplication par zéro qui fonctionne.
de même des fonctions ensemblistes sur l'ensemble vide peuvent donner l'ensemble vide.

Tu parles du cas inverse, ou tout est prolongé, c'est vrai qu'on se retrouverait avec le cas inverse.
C'est à dire que parfois on voudrait pas qu'il soit possible de faire

UNTYPE a = null;
UNAUTRETYPE u = a.uneFonction();

Donc du coup on devrait quand même en arriver à mettre un if testant si a est null autour de l'appelle de a.uneFonction(), donc je suis d'accord ça ne résous rien fondamentalement de faire tout l'un ou l'autre.

Mais on pourrait imaginer une syntaxe spéciale, par exemple a/Unfonction() qui permettrait d'activer ou non le prolongement par exemple
Enfin bref, je vois que ça existe ma question est satisfaite

et le "prolongement" resterait un comportement flou et indéfini.
Par contre: http://en.wikipedia.org/wiki/Null_Object_pattern
 

les cas où on peut utiliser ça sont assez rares en fait. surtout quand t'as pas de closures.
 

java et son utilisation abusive des interfaces, au secours

cette méthode peut s'avérer utile ouais, mais c'est pas généralisable

null ça pue la merde. Et pour ton truc, c'est le comportement d'Objective-C, et c'est stupide: tu te retrouves avec des nulls invisibles qui se balladent partout dans le soft, et habituellement ils arrivent à des endroits où ils sont pas censés arriver (remarques que ceux de Java font pareil)

Bah si, c'est généralisable au special case pattern. Et c'est généralement (mais pas systématiquement) utilisable.

 
le mec qui voulait pas utiliser d'entier primitif ...

ça n'a rien de stupide, c'est juste le comportement inverse
dans les deux cas tu retrouves dans des situations où tu dois faire des vérifications si c'est pas le comportement que tu désires.

Là je bosse bien en java avec une fille qui semble avoir une peur bleue des null pointer exception, alors que je trouve qu'au contraire quitte à les avoir, c'est une chance d'être sur que ton code est solide et n'a pas de comportement imprévu.
Avoir le prolongement possible tant que c'est prévu, et systématique ou alors indiqué par une syntaxe particuliere, je vois pas ça comme un problème que ça pète pas sur un null.

Là d'ailleurs la fille voudrait encore un autre cas, ça serait de pas avoir de type nullable, afin que ça pete jamais quand on laisse passer des incohérences de code
Mais derrière elle doit quand même tester que la valeur du type primitif encapsulé correspond bien à une valeur arbitraire valant null.

je me suis mal exprimé, je voulais dire péniblement généralisable autant pour moi
bref aussi peu généralisable que l'est l'héritage multiple en java avec l'utilisation d'interface quoi. (Autre sujet sensible )

quand ils peuvent être nullable oui, vu qu'utiliser une valeur arbitraire indiquant que le type est vide n'est pas généralisable.
genre utiliser -1 si on a que des positifs je trouve ça vulgaire

ben nan. soit tu traites tes nulls à la main, parce que tu sais pourquoi ils sont là et tu fais avec, soit tu branches ça si tu as un comportement par défaut que tu veux appliquer qd y'a rien d'autre à faire.

C'est supide quand même.

En quoi c'est un problème? C'est une merde infâme les NPE, tu sais pas d'où ça vient, tu sais pas où ça part et ça peut pêter n'importe quand. C'est l'une des exceptions les plus chiantes à débugger (en dehors des problèmes de concurrence)

Comme quoi elle est plus intelligente que toi, parce qu'elle a bien raison

Wat.

Ou alors t'inclus la notion de nullabilité dans le type, comme ça tu sais où tu risques un null et ou tu le risques pas.

wat

Le problème est qu'elle veut mettre des primitifs à la place d'objet sur des informations facultatives. (d'après ce que j'ai compris)
 
genre
 

int getNumeroDeRue() {
return nummeroDeRue;
}

quand il est pas présent, tu es pwned avec un type primitif.
 
 

int getNumeroDeRue() {
return nummeroDeRue;
}

de toutes facons dans ce genre de cas, il te faut une chaine., pour gérer le 2bis

public class CompteEnBanque {
    public int getTuneSurCompteCourant() {
      return tuneSurCompteCourant;
    }
    public int getTuneSurLivretA() {
      return tuneSurLivretA;
    }
}

si t'as pas de livret A tu retournes -1 ?
c'est pas sympas, t'as pas de compte et t'es déjà à découvert

une des plus faciles tu veux dire ?

Tu te prends une exception, ya pas de raison qu'on demande le contenu du livret A si t'as pas de livret A.

Bah non, tu sais que t'as un null mais savoir d'où il vient c'est pas nécessairement une mince affaire. Et habituellement ton bug il est pas là où la NPE pète (si t'avais pas de code de gestion de nulls c'est que tu t'attendais pas à en avoir un dans le coin) mais quelque part en amont à l'injection du null dans le runtime, et quand la NPE pète ben t'as aucune idée de la source du null en question.

  j'ai cru avoir lu ce genre de point de vue dans un livre de python

 
Et comment on le sait que t'as pas de livret A ? (c'est juste un exemple, de toutes façons)
 
Si t'as 15 champs de valeurs qui sont potentiellement non renseignables, tu vas devoir maintenir 15 booléens pour dire que ton champ est renseigné ou non ?
 

 
justement la question c'est est ce que c'est prévu ou non.
est ce que la valeur null à une signification sémantique pour cette donnée.
si oui alors il n'y a pas de raison que tu ne fasses pas le test.

L'utilisation des exceptions?

hum oui et non, mais plutôt faire :  
 

 
que  
 

sur un getter simple ouais, mais il faudrait pas que ça masque une exception d'un appel de méthode plus complexe

par exemple si t'as une npe imprévu dans ton doIt() tu voudrais sans doute pas que le catch la rattrape.

Bah dans ce cas précis j'ai laissé la porte ouverte non seulement à toutes les fenêtres mais à la possibilité du 2e cas: il est parfaitement possible d'avoir un

if(account.hasLivretA()) {
    account.getLivretA().getBalance();
}

Mais sinon oui, EAFP est un principe important en Python

if(account.hasLivretA()) {
    account.getLivretA().getBalance();
}

avec bien sur un

public class CompteEnBanque {
    public int getTuneSurCompteCourant() {
      return tuneSurCompteCourant;
    }
    public int getTuneSurLivretA() {
      return tuneSurLivretA;
    }
}

* c'est deux instances de Compte distinctes. Client { List<Compte> comptes; }
* thune, avec un h.
* Compte { public Thune getThune(); } Thune { double amount; Currency currency; }

 
Figure 35: l'art de repondre a cote de la question.

Pas nécessairement. Ca peut aussi être

public boolean hasLivretA() {
    return accounts.containsKey('livret A');
}

ou

public boolean hasLivretA() {
    return !(livretA instanceof NoAccount);
}

il y a des dizaines de possibilités pour gérer ce genre de cas en fonction de ton implémentation, du sens du vent et de ton utilisation du typesys

oui bien sur c'est mieux
mais bon c'était juste un exemple
et bon là tu encapsules tout de même ton type primitif avec un objet
là il y a currency qui sauve l'exemple quoi, mais à une variable près t'écopes pas de l'encapsulation

enfin tu peux ne pas toucher à du code existant avec ton exemple, et juste ajouter des nouvelles classes de compte, c'est sur.

public boolean hasLivretA() {
    return accounts.containsKey('livret A');
}

public boolean hasLivretA() {
    return !(livretA instanceof NoAccount);
}

c'était un peu une boutade

noooooon ?
(au passage, tu noteras que je ne fais que démonter un exemple qui ne tiens pas la route, pas répondre à une question)

C'est bien ce que je te "reproche". J'osais estimer que dans le topic estampillé "ELITE", on était au-dessus des puerilités des topic "blabla".

(d'un coté j'ai envie de te demander d'aller te faire foutre, d'un autre, je voudrais bien t'expliquer que je vois pas comment on pourrait débattre d'un problème en se basant sur un example qui ne montre pas le problème à la base)

En se basant sur un principe simple, l'abstraction.

PQ collectif, votre dernière page est très bien