From a065e04d529da1d847b5062a12c46d916408bf32 Mon Sep 17 00:00:00 2001
From: Peter Bengtsson <mail@peterbe.com>
Date: Tue, 8 Dec 2020 21:46:22 -0500
Subject: update based on https://github.com/mdn/yari/issues/2028

---
 files/fr/components.utils.import/index.html | 47 -----------------------------
 1 file changed, 47 deletions(-)
 delete mode 100644 files/fr/components.utils.import/index.html

(limited to 'files/fr/components.utils.import')

diff --git a/files/fr/components.utils.import/index.html b/files/fr/components.utils.import/index.html
deleted file mode 100644
index 7e0b6da116..0000000000
--- a/files/fr/components.utils.import/index.html
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: Components.utils.import
-slug: Components.utils.import
-tags:
-  - NeedsContent
-  - 'XPCOM:Liaisons_de_langage'
-  - XPConnect
-translation_of: Mozilla/Tech/XPCOM/Language_Bindings/Components.utils.import
----
-<p>
-
-</p><p>Cette méthode a été introduite dans <a href="fr/Firefox_3">Firefox 3</a> et est utilisée pour partager aisément du code entre différentes visibilités. Par exemple, il est possible d'importer <a href="fr/XPCOMUtils.jsm">XPCOMUtils.jsm</a> pour éviter de copier/coller de longs pavés d'enregistrement de composants XPCOM dans vos fichiers de composants.
-</p><p>Consultez le <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=238324" title="FIXED: Implement JavaScript code-sharing module system">bug 238324</a>, la documentation dans <a href="https://dxr.mozilla.org/mozilla-central/source/js/src/xpconnect/idl/xpccomponents.idl" rel="custom">xpccomponents.idl</a> ainsi que les tests dans <code><a href="https://dxr.mozilla.org/mozilla-central/source/js/src/xpconnect/tests/unit/" rel="custom">js/src/xpconnect/tests/unit/</a></code> pour plus de détails et des exemples.
-</p>
-<h3 id="Diff.C3.A9rences_avec_mozIJSSubScriptLoader" name="Diff.C3.A9rences_avec_mozIJSSubScriptLoader"> Différences avec mozIJSSubScriptLoader </h3>
-<p>Les différences avec <code><a href="/fr/docs/Mozilla/Tech/XPCOM/Reference/Interface/mozIJSSubScriptLoader" title="">mozIJSSubScriptLoader</a></code> sont les suivantes :
-</p>
-<ul>
-<li>Le comportement d'importation/chargement du même code depuis différents emplacements :
-<ul><li>le chargeur de sous-script évalue le code indiqué à chacune de ses invocations, avec l'objet global de l'appelant.</li>
-<li><code>Components.utils.import</code> évalue le code de chaque module une seule fois, dans sa propre visibilité.</li>
-</ul>
-<p>Par exemple :
-</p>
-<pre>var scope1 = {}, scope2 = {};
-Components.utils.import("rel:XPCOMUtils.jsm", scope1);
-Components.utils.import("rel:XPCOMUtils.jsm", scope2);
-assert(scope2.XPCOMUtils === scope1.XPCOMUtils);
-</pre>
-<p>à comparer avec :
-</p>
-<pre>var obj1 = {}, obj2 = {};
-var loader = Components.classes["@mozilla.org/moz/jssubscript-loader;1"]
-                       .getService(Components.interfaces.mozIJSSubScriptLoader);
-loader.loadSubScript(someURL, obj1)
-loader.loadSubScript(someURL, obj2)
-assert(obj1.XPCOMUtils === obj2.XPCOMUtils);
-</pre>
-<p>Cela signifie que <code>Components.utils.import</code> est plus adapté pour le partage efficace de code (et de données ?) entre différents scripts exécutés dans des visibilités différentes.
-</p>
-</li>
-<li>Le chargeur de sous-script accepte une URL vers le code à charger, tandis qu'<code>import</code> n'accepte que des URI <code>resource:</code> (celles-ci sont à documenter).</li>
-</ul>
-<p><br>
-</p>
-<div class="noinclude">
-</div>
-- 
cgit v1.2.3-54-g00ecf