Les collections sont pas très sympa à manipuler (sauf depuis le 1.6 si je ne me trompe et foreach).
Les collections etaient effectivement particulierement pete couille jusqu'a java5 et l'apparition des generics.
Le pb est que l'implem des generics est mauvaise (tu te tapes vite la tete contre les murs quand tu pousses un peu l'utilisation) et for each est foireux, car pas possible de modifier la collection "foreachee": ca cree un Iterator behind the scenes, et malheureusement, tu n'a pas acces a cet iterator, donc modif = ConcurrentModificationException dans la face.
Sur ce point la, tu as tout a fait raison.
Le probleme la est que Sun a les petoches de casser quoi que ce soit niveau compat avec java1.4/5 et anterieurs, et qu'on se traine donc des boulets.
A mon humble avis, faudrait qu'ils prennent leurs couilles a deux mains, cassent la compat' en disant "desole pour les familles, tout ca, mais merci pour tout l'poisson, hein", nous mettent des vrais generics, des vrais getter et setter (ie des properties, pas des methodes, cf ActionScript) et autres choses sympatoches.
Il parait que ça s'améliore un peu, les annotations sont quand même quelque chose de sympa (même si ça existe ailleurs) mais bon...
C'est pas qq chose de sympa, c'est juste de la balle. Les annotations spring et hibernate me rendent la vie infiniment plus facile au quotidien
impossible de retourner par exemple facilement un liste de valeurs.Si une méthode doit retourner plusieurs valeurs, il faut forcément passer par une structure dédiée (si on veut pas avoir des tableaux partout comme on trouve parfois...)
Alors la par contre...
Ce que tu veux faire est une grouikerie sans nom. Je trouve ca dans le code au boulot (ie une List non typee avec ungros bordel dedans), c'est 10 coups de trique en publique pour le cochon qui a commite ca).
Non, une methode retourne un et un seul objet. Ou rien du tout.
Non, elle ne modifie pas un tableau passe en entree comme ca se fait en C.
Ce genre de choses sont simplement degueulasses, c'est gerable en langage de script parce que tu vas avoir qq centaines de lignes ecrites par la meme personne, ca se fait en C parce qu'on peut pas trop faire autrement, mais dans un langage objet haut niveau, c'est a proscrire.
Une methode retourne un objet. Si elle doit retourner plusieurs choses qui ne sont pas liee (ie, qui ne sont pas membres d'un meme objet), c'est que ton design est a chier, ta methode fait beacuoup trop et tu DOIS la splitter en plusieurs autres methodes. et si tu vois pas l'interet de le faire, soit tu n'utilises pas le bon langage, soit t'es trop con. Je vote plutot pour la reponse 1, mais la 2 se voit quand meme de temps a autres.
Alors, ouais, ca implique plus de code, mais au moins ca te met des gardes fous, ton code ne va pas peter parce que jean guy a patcher la fonction et a change l'ordre des parametres.
[^] # Re: javascript
Posté par thedude . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 2.
Les collections etaient effectivement particulierement pete couille jusqu'a java5 et l'apparition des generics.
Le pb est que l'implem des generics est mauvaise (tu te tapes vite la tete contre les murs quand tu pousses un peu l'utilisation) et for each est foireux, car pas possible de modifier la collection "foreachee": ca cree un Iterator behind the scenes, et malheureusement, tu n'a pas acces a cet iterator, donc modif = ConcurrentModificationException dans la face.
Sur ce point la, tu as tout a fait raison.
Le probleme la est que Sun a les petoches de casser quoi que ce soit niveau compat avec java1.4/5 et anterieurs, et qu'on se traine donc des boulets.
A mon humble avis, faudrait qu'ils prennent leurs couilles a deux mains, cassent la compat' en disant "desole pour les familles, tout ca, mais merci pour tout l'poisson, hein", nous mettent des vrais generics, des vrais getter et setter (ie des properties, pas des methodes, cf ActionScript) et autres choses sympatoches.
Il parait que ça s'améliore un peu, les annotations sont quand même quelque chose de sympa (même si ça existe ailleurs) mais bon...
C'est pas qq chose de sympa, c'est juste de la balle. Les annotations spring et hibernate me rendent la vie infiniment plus facile au quotidien
impossible de retourner par exemple facilement un liste de valeurs.Si une méthode doit retourner plusieurs valeurs, il faut forcément passer par une structure dédiée (si on veut pas avoir des tableaux partout comme on trouve parfois...)
Alors la par contre...
Ce que tu veux faire est une grouikerie sans nom. Je trouve ca dans le code au boulot (ie une List non typee avec ungros bordel dedans), c'est 10 coups de trique en publique pour le cochon qui a commite ca).
Non, une methode retourne un et un seul objet. Ou rien du tout.
Non, elle ne modifie pas un tableau passe en entree comme ca se fait en C.
Ce genre de choses sont simplement degueulasses, c'est gerable en langage de script parce que tu vas avoir qq centaines de lignes ecrites par la meme personne, ca se fait en C parce qu'on peut pas trop faire autrement, mais dans un langage objet haut niveau, c'est a proscrire.
Une methode retourne un objet. Si elle doit retourner plusieurs choses qui ne sont pas liee (ie, qui ne sont pas membres d'un meme objet), c'est que ton design est a chier, ta methode fait beacuoup trop et tu DOIS la splitter en plusieurs autres methodes. et si tu vois pas l'interet de le faire, soit tu n'utilises pas le bon langage, soit t'es trop con. Je vote plutot pour la reponse 1, mais la 2 se voit quand meme de temps a autres.
Alors, ouais, ca implique plus de code, mais au moins ca te met des gardes fous, ton code ne va pas peter parce que jean guy a patcher la fonction et a change l'ordre des parametres.