Reprise du message précédent :
Je l'ai eu 4 fois en deux semaines
 
1 colis sans suivi, pas d'avis de passage : je vais à la poste le récupérer (au cas ou)
1 colis avec suivi, un avis de passage sans numéro, ni raisons (j'étais à la maison)
1 colis avec suivi, pas d'avis de passage, je vais le chercher à la poste.
1 colis sans suivi, pas d'avis de passage, je tente ma chance 3 fois avant de le récupérer
 

1.5 JOURS POUR TOMBER SUR UN BUG INSIGNIFIANT JOIEEEEEEEEE

 
chronopost, c'est la poste

 
mon frangin a bosser pour le suivi clientèle HP europe , ils traitaient les sav et les faisaient envoyer par UPS  
Certains ordi portable ont été posés sur une boite au lettre, balancé par dessus le portail ( ne passait pas par la fente de la boite au lettre) , et autres conneries

'tain y'avait que des meufs dans ton université

Vivement la privatisation  

ça explique pourquoi il voulait continuer les études tout ce temps!

Ca dépend, perso j'ai un tableau (ArrayList java) d'objets à filtrer ; je préfère faire remove sur l'ArrayList passé en entrée plutôt que de dupliquer le bordel sans les objets filtrés.

Bah t'as tord et t'es un trou de fion.

Déjà tu devrais pas avoir une ArrayList en entrée (ou en sortie) d'une fonction, tu devrais avoir une List, donc elle est potentiellement unmodifiable
Ensuite, grâce à google collections tu peux filtrer ta liste et renvoyer la nouvelle en 3 lignes
Enfin, ça devrait être pêne de mort, les gens qui modifient des paramètres

bah tout pareil. (enfin, quoique)

mais je pensais surtout à ça :

MyObject updateMyObject(final MyObject truc) {
 
  truc.setMonMachin(true);
  return truc;
}

Ca fait mal aux yeux quoi . Et sans voir le code de la méthode, c'est impossible de savoir si updateMyObject fait une copie ou non de "truc".

vive l'ADA avec ses paramètres in/out

merde, jovalise a encore changé de pseudo

MyObject updateMyObject(final MyObject truc) {
 
  truc.setMonMachin(true);
  return truc;
}

Bah non mais il retournerait même pas truc (enfin j'espère, sinon c'est au bucher ) donc

MyObject updateMyObject(final MyObject truc) {
  truc.setMonMachin(true);
}

...justement, ça retournait truc   Et vu le nom de la méthode, retourner "truc" est inutile. Bref, tout ça pour en revenir à "utilisez return à la place du passage par référence", je lulz dessus.

Ok ben au bucher

Je vois pas pourquoi je devrais passer une interface en entrée/sortie (surtout dans ce cas précis).

Rajoutons encore des dépendances à ce projet bloaté

 
Très franchement, ça me gêne de recréer tout une liste, surtout quand j'en connais pas la taille. Je trouve ça dégueulasse d'un point de vue perfs et, à partir du moment où c'est clairement documenté, je vois pas en quoi c'est si mal. En plus, dans mon cas, il s'agit d'une implémentation qui n'a pas vocation à se terminer en API.

Parce qu'il n'y a pas de raison de pas le faire, et parce que tu devrais toujours interagir sur les types les plus génériques possibles afin de réduire la taille de l'interface et de préciser au mieux les besoins de la fonction (ça sert aussi de documentation, si tu prends une arraylist en entier c'est que t'as spécifiquement besoin d'une arraylist, donc que tu fais des choses qui ont trait à des arraylists ou que tu as besoin des caractéristiques de perfs d'une arraylist, sinon tu prends une list, ou une collection).

Java, dude (et ya sûrement un truc du style dans les collection-utils)

Si t'as pas profilé, t'as pas le droit de parler de perfs

Et du code faux qui va vite, ben il sert à rien

Du code, c'est toujours une API pour le mec qui va arriver derrière et se taper la maintenance

Putain mais quel support en carton...je leur explique depuis le premier message exactement quel est le problème, d'où il vient et comment le corriger, mais non il leur faut encore 40 aller/retour pour vérifier...

Oui et non, et majoritairement non.

MyObject updateMyObject(final MyObject truc) {
  truc.setMonMachin(true);
}

Voilà, j'ai ça, mais parfois avec en plus une callback passée en paramètre a updateMyObject qui elle aussi contient un appel a une fonction qui modifie l'objet par référence

   PQ

C'est juste.
Sauf que là ça m'apporterait rien dans le sens où List dispose aussi de remove Tu dis que c'est potentiellement unmodifiable, sauf que faut partir du principe que tu sais pas si on t'envoie en entrée un truc modifiable ou pas ; ça, c'est une question que tu peux aussi te poser avec ArrayList
Bref, je suis d'accord qu'il faut

Ouais enfin collection-utils/Google collections/collections Mesgenoux, spareil, si je peux éviter d'en rajouter...

Sauf que tu pars du postulat que le code est faux Qu'il ne corresponde pas à telle ou telle règle de design OK mais fonctionnellement il fait tout à fait ce qu'on lui demande.
Quant aux perfs, y a une différence entre une optim à la con et la copie intégrale d'un tableau d'objets relativement lourds ou coûteux dont tu ne connais pas la longueur. Si je maîtrisais la taille du bordel ou si c'était une taille fixe OK, mais là ça peut être n'importe quoi.

Sauf que je vois pas en quoi c'est pas maintenable tant que c'est documenté un tant soit peu

la doc au temps T n'est plus bonne au temps T+1, alors se baser sur la doc, j'évite.
Keep it simple  

Sauf que pour une ArrayList unmodifiable faut hériter de ArrayList et flinguer les fonctions de modif, ça deviens pervers comme truc

Bah ouais mais collection-utils y est ptet déjà

Et quand je peux mettre une lib qui me simplifie le boulot et rend le code plus lisible, ben j'aime bien

Je pars toujours de l'idée que le code est faux

There is no doc And the doc which isn't there is false anyway And nobody reads the doc which doesn't exist and would be wrong if it were there

The code is the doc, if invariants are in code, they're correct

Ouais mais là y a une pelletée de dépendances Enfin ouais, je vais voir ça, y a p'têt un des trucs (enfin pas Gougueule, ça chu quasi-sûr).

Je trouve ça tellement triste, comme vision Ca me flingue toute envie de foutre des commentaires dans mon code

TORT AVEC UN T §§§ /FOU/ /MECHANT/ /FLORENTG/ /NATAS/

Moi aussi je connais Wikipédia, par contre y'a strictement aucun rapport au niveau gestion entre La Poste et Chronopost == irrelevant.

Also, j'ai jamais eu de problème avec UPS (delai, enlevement, livraison), ceci dit, j'imagine que les coursiers lazy existent oui.

 
j'enfonce le clou.
 

 
CQFD => chronopost = la poste.

 
moi non plus, j'ai jamais eu de pb avec UPS.
Et je te dirais que quand je commande par chrnopost, le livreur/coursier passe avec un fourgonnette jaune, siglé la poste

Pour moi UPS c'est les champions du "je mets un avis de passage sans même chercher à savoir si il y a quelqu'un" ; ça doit dépendre des livreurs je suppose.

En fait j'ai jamais été vraiment satisfait d'un service de livraison, 1 fois sur 2 je dois aller chercher le colis moi-même, sauf que par la poste il est mis en instance à 30m de chez moi...

 
ouais clairement

 
clients pro vs clients perso

Oui c'est exactement ça le problème : les boites genre UPS, TNT & co sont organisées pour le service aux entreprises. Pour la livraison aux particuliers, c'est encore la poste qui assure le plus.

 
wait wait wait, tu fais un remove() aléatoire sur un ArrayList de taille inconnue et tu viens parler de perfs ?    

j'espère que tu n'en enlèves qu'à la fin de la liste

C'est un cas particulier, comme quand tu te fais livrer depuis l'Angleterre en général Royal Mail fait le relai vers La poste pour X raisons. Chronopost à son propre réseau de livraison/traitement, ceci dit j'imagine qu'ils se servent de la maison mère dans certaines circonstances. Sinon ils ont bien leur camions avec des p'tits gars en tee shirt estampillé chronopost. ( les camions et les tee shirts, pas les p'tits gars )

Ça c'est parce que t'habites dans le sud

Edit : Ah merde c'est pas Harkonnen

Putain, super. On va revoir tout ça

je sais, j'en ai deja vu, mais chez moi, c'est systematiquement la poste qui livre
 

le conseil gratuit de nraynaud : tu copies les éléments dans une nouvelle liste en sautant ceux à virer.
 
si l'ensemble de ceux à virer est grand, transforme-le en hashSet ou treeSet avant (parce que tu vas faire une tonne de .contains() en O(n sinon))
en gros ta complexité finale ça sera taille de la liste à filtrer + taille de la liste des éléments indésirables, ce qui fait beaucoup moins que n^2 de la taille de la liste à filter+nb d'éléments à virer.

Conclusion : Si ton colis est en retard/et ou t'as un avis de passage mytho -> c'est de la faute de la poste (peut-être)

je faisais ça dans une appli python...  
 par contre, c'etait super simple a faire en quelques lignes