| hephaestos |
depart a écrit :
Je vois l'idée.
Pourtant il y a plein de langages qui se débrouillent sans souci avec ça.
Genre en PHP tu veux manipuler des fichiers par exemple (fopen, ...) sans avoir à inclure de librairie file.
Et comme c'est une fonction "native", personne ne va chercher a faire une librairie tierce avec sa propre méthode fopen qui rentrerait en conflit avec fopen. Où alors c'est très volontairement un choix assumé (remplacer une fonction native).
J'ai cherché un peu et certains évoquent aussi l'aspect sécurité : la logique serait que si tu as une faille dans la librairie Toto, que ton projet ne l'utilise pas mais qu'une personne mal-intentionnée arrive à injecter du code qui fait appel à cette librairie, si elle n'est pas automatiquement chargée lorsqu'on en a besoin alors elle ne risque pas d'être utilisée, alors qu'à l'inverse, il suffirait que le code malveillant cherche à s'en servir pour pouvoir y accéder.
Là encore je vois l'idée, mais dans le cas de code compilé, j'ai un peu plus de mal à comprendre : si tu t'en sers pas, elle n'est pas inclue, donc non utilisable.
|
Dans la plupart des languages, tu as trois couches :
- le language coeur, avec ses éléments propres dont l'implémentation est fournie avec le language
- la bibliothèque standard, qui rajoute des fonctionnalités en laissant le soin à l'utilisateur de fournir sa propre implémentation, et qui peut être ignorée
- tout le reste
Tout ce qui n'est pas dans le premier point ne peut pas être importé automatiquement par le language, ça doit être géré par une couche supplémentaire. La librarie standard est généralement gérée nativement par tous les IDE, et tout le reste ça fait l'objet de gestionnaires de modules qui permettent de se simplifier la vie pour partager des composants communs.
Maintenant, pourquoi on met pas tout dans 1 ? parce que d'une part ça rend le language bien plus compliqué à développer, et à faire évoluer; et d'autre part ça force les utilisateurs à importer des fonctionnalités qu'ils n'utilisent peut-être pas, ou qu'ils préfèrent importer d'ailleurs.. Selon les contraintes et les choix de chaque language, on va retrouver des fonctionnalités plus riches fournies nativement, et la plupart des languages aujourd'hui vont notamment proposer des bibliothèques standard pour l'interface graphique, mais ils gardent cette structure en oignon qui permet d'avoir une couche externe riche et véloce. Comme il t'a été répondu plus haut, même si c'est effectivement pénible à l'utilisation au premier abord, il existe des outils qui, s'ils sont correctement choisis et configurés (ce qui rajoute une grosse couche de friction), permettent de gérer ça au quotidien presque comme si ces foncitonalités étaient natives. |