Dans les languages que vous pratiquez et ayant une notion de package/module/namespace, est-ce que le style habituellement conseille par les experts est
- d'importer les noms des package/module/namespace pour les utiliser non qualifies

- de qualifier les noms par un alias plus ou moins local du package/module/namespace

- de qualifier les noms par le nom complet du package/module/namespace

- ou autre chose encore
Et est-ce que votre pratique est difference de celle conseillee,  Si vous avez des commentaires sur le sujet, je suis preneur.

Actuellement  en java : non qualifié, sauf lorsque c'est sujet a risque de confondre
 
Avant C++ : c'est quoi un nmamespace par 80% de l'equipe
 
Ada : solution 2. Obligation d'utiliser les noms de namespace, mais on avait des alias de package pre-créés utilisables.
 
plus que du langage, ca depend des normes de code en vigueur

En Python, les imports sont généralement assez plats, donc les préférences (PEP8 + communauté, pas juste une préférence perso) dans l'ordre:
1. Import qualifié complet

import foo
import spam.eggs
 
bar = foo.Bar()
blob = spam.eggs.Gnu() # pas nécessairement super fréquent, 2 niveaux c'est déjà beaucoup en Python

2. import qualifié aliasé

import spam.eggs as bob
 
blob = bob.Gnu()

3. qualification partielle

from spam import eggs
 
blob = eggs.Gnu()

4. déqualification explicite

from spam.eggs import Gnu
 
blob = Gnu()

La seule version qui soit vraiment déconseillée étant l'import complet non qualifié à la Java:

from spam.eggs import *
 
blob = Gnu()

Pour les languages tels que C++ (bon en fait j'en ai aucun autre du genre en tête), faut bien faire la distinction entre la pratique coté header et coté implé.
 
En java c'est plutôt non qualifié (avec les IDE modernes qui ont tendance à automanager la liste des imports tout seuls), mais faut dire qu'on peut pas faire d'alias local malhereusement.
 
Pour python, l'import complet à coup d'étoile est déconseillé, sauf pour certains modules qui sont conçus pour être utilisé de la sorte (tkinter par ex. qui est dans la lib standard), et dans le cas des modules qui servent de DSL (outils de build par ex.)
 
Et faut faire gaffe que selon les langages, le contenu de "foo.bar" n'est pas forcément importé quand on importe "foo".

Pour info, mon contexte est celui d'une extension d'un langage existant pour ajouter une notion de namespace.
 
Mon point de vue, c'est que meme si on permet d'utiliser de maniere non qualifiee, on arrive avec l'experience a la situation decrite par Masklinn, l'import non qualifie ne fonctionnant qu'avec une convention de nommage evitant les clash.  Et comme il y a une assez forte probabilite de developpement independant devant etre utilises simultanement, penser que le mode d'import permettant l'utilisation non qualifee va etre la norme est s'illusionner.   Je cherchais a voir si l'experience generale correspondaient a la mienne.
 

 
Avec beaucoup de cas ou il y a des risques?  Avec des mesures preventives dans les regles de codages (prefixes)?
Quelle taille de projet?  Avec des developpements quasi-indépendants?
 

 
On se retrouve alors des prefixes pour eviter les collisions.
 

 
Si tu as des conventions qui evitent les clash, le packaging sert peu.

 
Je connais pas assez Java.  Pour reprendre les exemples de Masklinn, c'est l'equivalent de

ou de

qui est fait.
 
Le premier me semble envisagable pour autant qu'il soit maintenu automatiquement.
 
Le second me semble problematique, sauf a avoir une convention de nommage prevue pour eviter les problemes, ou une granularite vraiment fine qui en fait presque l'equivalent du premier.

Oui, mais ce sont habituellement des vieux modules.

Pas nécessairement, les modernes en tout cas ont souvent peu de fonctions donc c'est plus de la déqualification explicite.

Absolument

Sinon, histoire de, en Haskell la syntaxe est très similaire à celle de Python sauf que (et c'est quelque chose que j'aime assez peu) import Data.Map importe à la fois en qualifié et en déqualifié, donc

import Data.Map
 
-- ici tu as à la fois Data.Map.insert et directement insert

.

D'un autre côté, et contrairement à Python, l'export est explicite (chaque module définit précisément ce qu'il expose). Et l'import de Haskell est plus flexible (par exemple il est possible d'écrire l'équivalent de from foo import * except (a, b, c) qui importerait tout le contenu de foo sauf a, b et c), et naturellement il est très statiquement typé.

Mais bon, même avec ça je suis pas fan des imports non qualifiés par défaut. En dehors de ça, pour autant que je sois concerné, à part pour ce problème le système d'imports/exports de Haskell est le meilleur que j'ai pu voir.

Les deux sont possibles, mais comme les namespaces java tendent à être très profonds (genre com.google.common.collect avant même d'avoir atteint les classes) il est relativement fréquent qu'au delà de 3 ou 4 imports depuis le même namespace les IDEs soient configurés pour switcher automatiquement à du star-import.

Les accès non qualifiés sont également possibles, mais pas importés (genre spam.eggs.Gnu() dans le code ne sera pas précédé d'un import dans le header)

Non parce que la règle est que les noms de packages débutent plus ou moins par l'inverse des noms de domaine.
Ainsi les packages que l'on développe pour le projet Killerapp chez kikoulol.com commenceront par com.kikoulol.killerapp.*
Si tout le monde suit cette règle, les risques de collision sont très faibles (pour un même classloader). Comme tout en Java, c'est verbeux et assez bourrin, mais ça fonctionne pas mal.

Heuu t'as complètement raté le problème que mentionne kadreg, qui est que com.kikoolol.killerapp.FactoryFactory et com.jovalise.gnu.FactoryFactory ça rentre en collision quand tu les importes au même endroit. Et comme Java n'aliase pas les namespaces, tu auras l'honneur et l'avantage d'en garder un intégralement qualifié.
 
C'est également drôle quand tu définis une classe avec le même nom que l'un de tes imports.

J'ai rien raté du tout. Dans la pratique, même sur de projets avec des dizaines de milliers de classes réparties sur 150 jars, ça arrive très rarement qu'on ait à qualifier complètement un nom. Et c'était la question d'Un Programmeur: non pas de savoir si les collisions étaient impossibles, mais si ça arrive souvent dans la pratique. La réponse est clairement non.

Oui mais non, toute ta réponse est sur des noms de packages alors que ça n'a strictement aucune influence sur les problèmes de collisions, qui est sur les noms de classes

La seule partie de ta réponse qui corresponde à sa question, c'est le premier mot

Je ne sais pas de quoi tu parles, moi je parle de noms qualifiés. Je ne vois pas ce que la distinction package/classe vient faire la-dedans.

Étape 1: Kadreg indique qu'en Java les imports sont non qualifiés sauf s'il y a collision
Étape 2: Le Programmeur demande si les problèmes de collisions (de noms non qualifiés, donc) sont fréquents et s'il y a des moyens d'y remédier
Étape 3: tu indiques que quand on utilise des noms qualifiés en java il y a peu de risques de collisions, ce qui n'était pas du tout la question (et qui semble relativement... logique, dans la mesure où le but de la qualification est justement d'éviter les collisions)

Ca ne veut rien dire. C'est quoi un import non qualifié en Java ? Ce qu'a écrit kadreg, c'est que les noms sont non qualifiés dans le code en Java (sous-entendu PARCE QUE les imports sont là et sont suffisants pour qualifier les noms implicitement). Sauf dans le cas où il y a deux noms identiques dans le même source, auquel cas on est obligé de les qualifier explicitement.

Non, UP demande si la situation que j'ai décrite juste au-dessus (l'obligation de qualifier explicitement dans le code) est courante. Elle le serait s'il n'y avait pas la règle de nommage que j'ai indiquée. Non seulement elle serait courante, mais elle serait pratiquement mortelle parce qu'il n'y aurait jamais de garantie que deux fournisseurs de librairies qui développent chacun de son coté n'utilisent pas les mêmes namespaces. Or les librairies sont liées dynamiquement, donc il n'y a jamais de garantie qu'il n'y a pas un clash à l'exécution. C'est le sens de la question d'UP. Java ne garantit pas au niveau du mécanisme qu'il n'y a pas de collision, mais il fournit une règle de nommage qui les évite si tout le monde s'y colle. C'est pour ça qu'il est interdit de créer une classe en-dehors de tout package, même si le langage le permet.

Perso j'ai compris comme Maisklinn, et je serai pas trop rapide à dire que les collisions arrivent quasiment jamais. Le produit phare de ma boite c'est une vingtaine de jars et l'équipe de dev à réussi à nous en coller (on va dire qu'ils sont pas très doués). Et avec des jar externes, t'as vite fait d'avoir plusieurs classes avec le meme nom... bon après faut aussi avor à les utiliser en meme temps.
 
Typiquement un que j'ai rencontré moult fois ces dernier temps c'est des classes déclarées dans sdonm.jar (gestion de réseaux géographiques fourni par Oracle). Ben ma boite réplique quelques fonctionnalités, et évidemment les composants de base du réseau dans chaque librairie ont les memes noms de classe -> Node, Link, Path.
 
Et là tu vois aussi que des noms de classe aussi géneriques que Node, Link et Path tu vas les retrouver dans plein de contextes... Node en géométrie, Path pour la gestion de fichier, etc... Bref, les collisions, ca arrive pas tous les jours mais c'est pas si rare.

OK j'ai compris; Masklinn parle de collision dans un fichier, moi je parle de collision à l'échelle d'un projet. Pour moi, la question de UP n'a réellement de sens qu'à l'échelle d'un projet.
Ma réponse est donc identique, et est complètement correcte parce que la convention de nommage adoptée (et Dieu merci largement utilisée) réduit énormément le risque de collision (à l'échelle d'un projet). Autrement dit, le besoin de qualifier les noms dans le code est peu courant UNIQUEMENT à cause de la règle de nommage adoptée par tout le monde. Par exemple, dans les gros projets Java, il n'est pas rare qu'il y ait 2 ou 3 librairies XML et plus d'une lib de persistence, chacune avec des centaines de classes.
Et pourtant, il n'y a pratiquement pas de collisions.
Pourquoi ? A cause de la convention de nommage, tout simplement. Si elle n'existait pas, il serait très risqué d'utiliser plus d'une lib XML à la fois parce qu'on a vite fait de nommer son package xml.serializer. En C++, il n'y a pas cette convention et c'est ce qui rend obligatoire le keyword namespace, pas juste le besoin de réduiire de la frappe sur le clavier.

Pour qu'il y ait collision dans un fichier Java, il faut que  dans la même classe:
1., tu aies à la fois besoin de aa.Bb.Link ET xx.Yy.Link
2. que aa.Bb.Link et xx.Yy.Link soient toutes deux des fonctions statiques (parce que si aa.bb et xx.yy sont des classes instanciables, on appellerait les méthodes/membres des instances et il n'y a pas d'ambiguité).
On voit bien que ça n'arrive pas souvent. Et la convention de nommage empêche tout risque de collision à l'échelle du projet (le problème que soulève UP quand il dit " Et comme il y a une assez forte probabilite de developpement independant devant etre utilises simultanement" ). Enfin, le mécanisme des classloaders assure l'isolation dans une même JVM (dans un serveur d'appli, par exemple).

Pour ton exemple, tu t'en doutes aussi en codant, que Node, Link Path risque d'être déjà utilisé. Ceci dit ça ne doit en aucun cas être un frein. Mais arriver à répliquer des fonctionnalités déjà existantes avec juste 20 jars, -surtout si ce sont des fonctionnalités suffisamment majeures pour que les homonymes soient utilisés partout -, c'est pas très fort. Si c'est souvent le cas dans ton projet, soit c'est parce qu'ils veulent peu à peu remplacer une librairie par une autre isofonctionnelle,  soit vos devs sont effectivement pas super doués.

C'est un import tout court, java n'ayant pas d'imports qualifiés (mais ayant des usages qualifiés sans imports)

Oui et t'as pas répondu à la question

Wat

Non. Il est pas complètement con aux dernière nouvelle UP, je pense qu'il a déjà réalisé que si deux namespaces ont le même nom, tu vas avoir des problèmes pour spécifier auquel tu veux accéder.

Bah c'est complètement con, tout le thread est à propos de la qualification des noms dans les imports Parce que UP est justement en train d'implémenter un système de namespaces dans un langage existant et veut voir comment les autres gèrent leurs imports.

Ou des classes

Bah non, justement, d'où la question. J'ai déjà rencontré le problème Suffit de faire un peu de wrapping d'une lib existante et tes chances augmentes dramatiquement

Bon j'arrête, cette discussion me fatigue. Un Programmeur saura faire le tri.

 
Je parlais bien du fichier (ou d'une portee plus petite si on peut limiter la zone ou il n'y a pas besoin de qualification), pas du projet.  
 

 
Pour moi, a l'echelle du projet le probleme est resolu depuis longtemps.  On allonge les noms avec des prefixes pour diminuer le risque de conflits.
 
Le probleme, c'est a l'echelle locale.  Plus on allonge les noms, moins le code est lisible.  Les petits jeux avec les portees et l'import explicite ou non des noms fournissent la possibilite d'utiliser des alias courts locaux, tout en ayant des noms absolus peu sujet a conflits.  Mais alors, on retombe avec le risque de conflits, locaux.  D'autant plus que les packages en tant que fournisseurs de prefixes (ils ont aussi d'autres utilites, mais ce n'est pas mon sujet) incitent a utiliser des noms generiques (comme le Node cite ci-dessus) quand seul un debutant total l'aurait jamais fait dans un namespace global, meme en l'absence de conventions imposants  des prefixes (au pire on aurait utilise GraphNode ou NetNode).
 
Je pourrais donc reformuler ma question:
 
Etant donne que les packages resolvent le probleme de conflits de noms a l'echelle globale, mais l'aggravent a l'echelle locale, comment votre pratique resouds cette tension?  Et, sachant qu'on vit dans un monde de compromis, qu'est-ce que vous considéreriez comme bonnes pratiques en la matiere?
 
(Pour moi, ce que donne Masklinn correspond a mon idee de la chose -- le choix entre 1 et 2 devant se faire sur des considerations particulieres --, mais je ne pretends pas avoir une connaissance universelle et je suis dans une situation ou je peux tirer quelque choses d'autres points de vue).
 
Dire qu'on ne la voit pas en pratique est une reponse.  Tres interessante d'ailleurs car elle remets en cause mes pre-conceptions.  Comme ce n'est pas facile a admettre et que je me base quand meme sur une experience pratique et non uniquement des considerations theoriques, je me demande de suite quel est le facteur dont je n'ai pas connaissance qui intervient, le premier venant  
a l'esprit est l'echelle des projets, est-ce qu'elle assez importante pour qu'elle soit pertinente dans mon contexte.

IMO 4 est également valable dans certaines situations particulières (3 moins, parce qu'on peut arriver au même résultat via 2), quand ça simplifie réellement le code, tout particulièrement si on peut le combiner à 2, aliaser les symboles déqualifier:

from decimal import Decimal as d

 
Encore une fois, je te recommande d'aller regarder les modules Haskell, qui sont très bien fait avec le seul problème de l'import à la fois qualifié et non qualifié par défaut qui est beurk (faudrait juste que "import qualified" soit le cas par défaut, en fait, et pas besoin du hiding si tu gères pas d'équivalent au star-import)
http://en.wikibooks.org/wiki/Haskell/Modules
http://www.haskell.org/onlinereport/modules.html
http://www.cs.auckland.ac.nz/refer [...] dules.html
http://www.haskell.org/hierarchical-modules/

from decimal import Decimal as d

Je restais dans le general.
 

J'avais note.  J'ai juste quelques petites taches vulgaires comme rebaser 6000 fichiers et apres je peux m'occuper de choses plus interessantes.