Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #39748

Re: Exposing a module in the current scope

From Anton Shepelev <anton.txt@g{oogle}mail.com>
Newsgroups comp.lang.javascript
Subject Re: Exposing a module in the current scope
Date 2021-03-23 20:06 +0300
Organization A noiseless patient Spider
Message-ID <20210323200626.83adf6ef1ebae253d8e5d04f@g{oogle}mail.com> (permalink)
References <20210318192107.08e2fac2d6aeada5596c4dd0@freeshell.de> <1777535.tdWV9SEqCh@PointedEars.de>

Show all headers | View raw


Thomas 'PointedEars' Lahn:

> But an alternative standard-compliant and backwards-
> compatible way is what has been called an IEFE
> ("immediately executed function expression") or a simiilar
> term:
>
>    $.import("anton_test/util.xsjslib","util"); // import module
>    $.anton_test.util.log("Log from library."); // invoke a function
>
>    (function (log) {
>      /* ... */
>    }($.anton_test.util.log));

You invoke an immediate function with the log function as
the parameter. What for? -- to create a scope with it
acessible by the name of `log'?

> The same caveat applies above as for
>
>    const log = $.anton_test.util.log;
>
> which is why typically one writes
>
>    (function (util) {
>      util.log("Log from library.");
>    }($.anton_test.util));

Now you invoke an immediate function with the module as the
parameter, and that function invokes util.log() internally.
In what way is it better than the previous version? Still
missing your point, I looked IEFE up on Wikipedia, but their
example of IOEFE benefits seems flawed from the start:

   var v, getValue;
   v = 1;
   getValue = function () { return v; };
   v = 2;

   getValue(); // 2

is rewritten as:

   var v, getValue;
   v = 1;
   function f(x) {
       return function () { return x; };
   };
   getValue = f(v);
   v = 2;

   getValue();  // 1

Why on earth would anyone want to write a function that
accesses/captures a global variable, instead of remembering
whatever value is required and passing it as a parameter
whenever it must be used? For aught that I understand, the
Wikipedia example seems to demonstrate that generating a
function with an explicitly specified captured data gives
more control and safety. It is a nicety of functional
programming that has nothing to do with procedural, where
data is not magically attached to functions.

Since I very rarely write functions that access global
variables (any data not passed in the parameters), unless it
be some application-wide settings, I think I need not care
about such details. If the log function does not access
global variables,

   const log = $.anton_test.util.log;

should be perfectly safe, right?

> BTW, I would expect the module loader of such a module
> system to return, if successful, a reference to the module
> object such that Ц if synchronous execution cannot be
> avoided -

Why avoid it? -- it simpler and easier to understand and
reason about than asynchromous operation.  I would act the
other way -- resort to asynchronous stuff when it cannot be
avoided, for performace or other reasons.

> the following code would be equivalent to the code above:
>
>   const util = $.import("anton_test/util.xsjslib","util");
>   util.log("Log from library.");

At least -- this code is more strucutured in returning the
loaded module instead placing it somewhere by way of a side
effect, but the documentaition to my system says nothing
about the return value of this import() function.

> In asynchronous module loading, typically the module
> object is passed as argument to the callback:
>   $.import("anton_test/util.xsjslib", function (util) {
>     util.log("Log from library.");
>   });

I see. I have used callbacks for asynchronous initialisation
and network commnication, e.g. send a packet and register a
callback to handle the reply or a timeout event, or register
settings and provide a continuation callback to initialise
the parts that depend upon the settings.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Exposing a module in the current scope Anton Shepelev <antonius@freeshell.de> - 2021-03-18 19:21 +0300
  Re: Exposing a module in the current scope Anton Shepelev <anton.txt@gmail.com> - 2021-03-18 23:57 +0300
    Re: Exposing a module in the current scope "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-18 18:45 -0700
      Re: Exposing a module in the current scope Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-03-19 18:11 +0300
        Re: Exposing a module in the current scope Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-03-19 19:08 +0300
          Re: Exposing a module in the current scope "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-19 10:51 -0700
            Re: Exposing a module in the current scope Anton Shepelev <anton.txt@gmail.com> - 2021-03-20 13:32 +0300
              Re: Exposing a module in the current scope "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-20 09:53 -0700
        Re: Exposing a module in the current scope "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-19 10:47 -0700
          Re: Exposing a module in the current scope Anton Shepelev <anton.txt@gmail.com> - 2021-03-20 13:51 +0300
            Re: Exposing a module in the current scope "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-20 09:59 -0700
              Re: Exposing a module in the current scope Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-03-24 20:43 +0300
          Re: Exposing a module in the current scope Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-03-22 21:14 +0100
            Re: Exposing a module in the current scope "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-22 16:00 -0700
              Re: Exposing a module in the current scope Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-03-23 01:11 +0100
              Re: Exposing a module in the current scope Anton Shepelev <anton.txt@gmail.com> - 2021-04-04 00:31 +0300
  Re: Exposing a module in the current scope "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-03-18 11:30 -0700
  Re: Exposing a module in the current scope Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-03-22 21:05 +0100
  Re: Exposing a module in the current scope Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-03-23 01:00 +0100
    Re: Exposing a module in the current scope Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-03-23 20:06 +0300
      Re: Exposing a module in the current scope Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-03-25 20:04 +0100
        Re: Exposing a module in the current scope John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-26 08:32 +0000
        Re: Exposing a module in the current scope John G Harris <niam@jghnorth.org.uk.invalid> - 2021-03-26 08:48 +0000
  Re: Exposing a module in the current scope Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-04-13 18:49 +0300

csiph-web