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

Groups > comp.lang.javascript > #39767

Re: Exposing a module in the current scope

Show all headers | View raw

Anton Shepelev wrote:

> 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.

No, I am passing a *reference* to the Function instance as the _argument_
of the anonymous function, therefore that becomes the _value_ of the formal 
parameter “log”, and the evaluation result of the _identifier_ “log” in the 
function execution context.

> What for?

So that you can write log(…) inside that function, which is what
*you* wished to do.  But actually, AISB, the safe way would be to pass 
$.anton_test.util.log.bind($.anton_test.util).  See below.

> -- to create a scope with it
> acessible by the name of `log'?

You have a misconception as to what the word “scope” means, and what a scope 
is in ECMAScript implementations.

>> 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?

Then there is no risk of getting a wrong “this” value inside log(), so no 
need to use Function.prototype.bind() to use the correct value, and 
potentially reduce efficiency.

> 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

This is NOT an IEFE.

> Why on earth would anyone want to write a function that
> accesses/captures a global variable,

It does not.  The point of this example, which has absolutely nothing to do 
with what I discussed, is to "capture" the *value* of the variable at the 
time that the returned function was *created*.  Regardless of the current 
value of the variable “v”, the created function, which is referred to by 
“getValue”, will always return 1.

Look up “closure”.

> […] If the log function does not access global variables,
> 
>    const log = $.anton_test.util.log;
> 
> should be perfectly safe, right?

Wrong, AISB.  Run this:

  var answer = 23;

  const my = {
    answer: 42,
    log: function () { console.log(this.answer); }
  };

  /* Non-strict mode */
  (function () {
    my.log();

    const log = my.log;
    log();

    const log2 = my.log.bind(my);
    log2();
  }());

  /* Strict mode */
  (function () {
    'use strict';

    my.log();

    const log = my.log;
    log();

    const log2 = my.log.bind(my);
    log2();
  }());

N.B.: Using “const” or “let” instead of “var” avoids the output of “23”
in both modes as variables declared in the new way do NOT become properties 
of the global object when declared in the global execution context; but 
“undefined” is put out when we still wanted to see “42” instead.
 
>> 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 blocks execution of other code due to the single-threadedness of the 
ECMAScript execution process; in a Web browser that also means that it 
blocks the current tab, all other tabs in the same window, or the entire Web 
browser.

Therefore, synchronous XHR, for example, is deprecated in at least Chromium 
since several versions, and support for it might be removed in the future.

> […]

Your overconfident statements are indicative, as they are unfortunately 
typical, for a "JavaScript" beginner (who derives their "knowledge" only
from the unfortunately many bad books and articles on the topic).

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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