Oui, je suis du genre à imaginer le langage avec la syntaxe parfaite. Je me demande si la majorité des développeurs avec un peu d’expérience ne sont pas comme ça en fait.
Je me suis remis à Ruby après un moment en Javascript et je confirme mon impression précédente : Je veux des imports explicites en début de fichier pour chaque chose que j’utilise et qui est défini en dehors, pas d’espace de nom global créé par ailleurs.
J’ai repris mes anciennes notes et voilà où j’en suis :
L’import se fait par défaut par rapport à la racine du projet/paquet courant.
import MonComposant
import Module/SousModule/MonComposant
Même chose pour les imports relatifs, pour peu qu’ils commencent par un point. Oui, ce sont des chemins mais je tiens à ce que les délimiteurs soient facultatifs (qui s’amuse à mettre autre chose que de l’alphanumérique dans ses chemins internes ?)
import ./Module/SousModule/MonComposant
import ../Module/SousModule/MonComposant
Les paquets externes (gem, npm, packagist, cpan…) sont référencés par une arobase, et une table de correspondance à la racine du projet/paquet courant :
import @Paquet
import @Paquet/Module/SousModule/MonComposant
L’import utilise par défaut la dernière partie de la chaîne d’import comme nom local (on évite l’obligation de se répéter qu’on trouve dans trop de lignes d’import Javascript).
Pour éviter les conflits de nom et faciliter des noms plus adaptés au code local, on ajoute des alias :
import MonComposant as AliasLocal
import Module/SousModule/MonComposant as AliasLocal
import @Paquet as AliasLocal
import @Paquet/Module/MonComposant as AliasLocal
J’aime bien les exports nommés de Javascript, qu’un point d’entrée puisse référencer plusieurs composants.
Je récupère ici la syntaxe Python qui permet de toujours placer l’origine en première position. Ça se discute, on pourrait aussi le faire dans l’autre sens.
from Module/SousModule import MonComposant
from ./Module import MonComposant
from @Paquet/Module import MonComposant
from Module import Composant1, Composant2
from Module import Composant1, Composant2 as MonAlias
Quitte à faire des alias, c’est bien de pouvoir récupérer une méthode ou un sous objet sans qu’il n’y ait d’export nommé.
C’est toujours la dernière partie de ce qui est importé qui définit le nom local par défaut/
from Module/MonComposant import .maMethode
from MonComposant import .SousModule.maMethode
from ./MonComposant import .Foo.bar, .maMethode
from @Paquet/MonComposant import .Foo.bar as alias
Laisser un commentaire