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

Groups > comp.lang.javascript > #39693 > unrolled thread

Exposing a module in the current scope

Back to article view | Back to comp.lang.javascript

Contents

  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

Page 1 of 2  [1] 2  Next page →

#39693 — Exposing a module in the current scope

Hello, all

It looks like in the system for which I need to write
server-side JavaScript, neither CommonJS nor ECMAScript
modules are supported, but it provides its own module system
that works as shown below:

   $.import("anton_test/util.xsjslib","util"); // import module
   $.anton_test.util.log("Log from library."); // invoke a function

Is it somehow possible to have all the functions from `util'
available in the current scope, so that I could invoke them
by their names: log("Hello"), rather than, say,
util.log("Hello"), without enumerating them in a
destucturing assignment. If analogies with other languages
can help, then it would be like `uses` in Borland Pascal,
`using static` in C#, or `#include` in C.

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

[toc] | [next] | [standalone]

#39694

Michael Haufe:

> Are you using node js?

Unfortunately, I am using a thing called SAP Hana XS
(Classic):

   https://help.sap.com/viewer/d89d4595fae647eabc14002c0340a999/1.0.12/en-US

which is not aware of `require' and complains about `import'
that it must occur at the top level of a module, as if it
were genuine NodeJS:

   https://answers.sap.com/questions/13319612/can-one-use-ecmascript-modules-in-a-hana-xs-applic.html

> <https://nodejs.org/api/esm.html>
> Did you name the file *.mjs ?

I have already read that document about ECMAScript modules
in NodeJS, but it does not apply to Hana XS, where the files
must have extension .xsjs. I tried playing with the `type'
parameter in package.json, but it didn't help either.

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

[toc] | [prev] | [next] | [standalone]

#39702

On Thursday, March 18, 2021 at 3:57:10 PM UTC-5, Anton Shepelev wrote:
> Michael Haufe:
> > Are you using node js?
> Unfortunately, I am using a thing called SAP Hana XS 
> (Classic): 
> 
> https://help.sap.com/viewer/d89d4595fae647eabc14002c0340a999/1.0.12/en-US 
> 
> which is not aware of `require' and complains about `import' 
> that it must occur at the top level of a module, as if it 
> were genuine NodeJS: 
> 
> https://answers.sap.com/questions/13319612/can-one-use-ecmascript-modules-in-a-hana-xs-applic.html
> > <https://nodejs.org/api/esm.html> 
> > Did you name the file *.mjs ?
> I have already read that document about ECMAScript modules 
> in NodeJS, but it does not apply to Hana XS, where the files 
> must have extension .xsjs. I tried playing with the `type' 
> parameter in package.json, but it didn't help either. 

I can't tell from the docs what version of JavaScript is being used.

Does the following code throw an error?

```
class Foo{}
```

If it does then I suspect some implementation of ECMAScript 5 is what's being used.

There are no modules or classes in that version. 

Based on the following:

<https://help.sap.com/viewer/b3d0daf2a98e49ada00bf31b7ca7a42e/2.0.03/en-US/8a9cdd1242654ccd86ba113630e77830.html>

I think the approach is to do it the old school way:

```
// myLibrary.xsjslib
(function(){
  "use strict"

  function Point2(x, y) {
    this.x = x
    this.y =y
  }
  Point2.prototype = {
    constructor: Point2,
    equals: function(point2) {
      return point2 instanceof Point2 && point2.x === this.x && point2.y === this.y
    },
    toString: function(){
      return "(" + this.x + "," + this.y + ")"
    }
  }

  var _modulePrivate = "Secret Squirrel"

  function Person(name, age) {
    this.name = name
    this.age = age
  }
  Person.prototype = {
    constructor: Person,
    sayHello: function(){
      return "Hello " + this.name + "!"
    },
    // other methods
  }

  // The following exposes all of the variables for your "module"
  return {
    Point2,
    Person
  }
})()
```

Then the usage I believe would be:

```
$.import("<path.to.your.library.filename>","myLibrary");
var myLibrary = $.<path.to.your.library.filename>;

var p2  = new myLibrary.Point2(12, 15);

var john = new myLibrary.Person("John Doe", 32)
```

[toc] | [prev] | [next] | [standalone]

#39705

Michael Haufe:

> I can't tell from the docs what version of JavaScript is
> being used.

The documentation leaves much to be dreamed of.

> Does the following code throw an error?
>
> ```
> class Foo{}
> ```

No, it works. Why are you writing in Markdown?

> If it does then I suspect some implementation of
> ECMAScript 5 is what's being used.  There are no modules
> or classes in that version.

As I wrote, it does recognise the `import' statement, but
fails with:

   import declarations may only appear at top level of a module

presumably because it cannot treat .xsjs files as modules.

> I think the approach is to do it the old school way:
>
> ```
> // myLibrary.xsjslib
> (function(){
>   "use strict"
>
>   function Point2(x, y) {
>     this.x = x
>     this.y =y
>   }
>   Point2.prototype = {
>     constructor: Point2,
>     equals: function(point2) {
>       return point2 instanceof Point2 && point2.x === this.x && point2.y === this.y
>     },
>     toString: function(){
>       return "(" + this.x + "," + this.y + ")"
>     }
>   }
>
>   var _modulePrivate = "Secret Squirrel"
>
>   function Person(name, age) {
>     this.name = name
>     this.age = age
>   }
>   Person.prototype = {
>     constructor: Person,
>     sayHello: function(){
>       return "Hello " + this.name + "!"
>     },
>     // other methods
>   }
>
>   // The following exposes all of the variables for your "module"
>   return {
>     Point2,
>     Person
>   }
> })()
> ```
>
> Then the usage I believe would be:
>
> ```
> $.import("<path.to.your.library.filename>","myLibrary");
> var myLibrary = $.<path.to.your.library.filename>;
>
> var p2  = new myLibrary.Point2(12, 15);
>
> var john = new myLibrary.Person("John Doe", 32)
> ```

This looksj rather complicated to me: the library consists
of the result of the execution of an anonymous function. I
have tried this approach with my test library, but failed.
Here is my original working library:

   // file util.xsjslib:
   function log(msg)
   {  $.trace.debug(msg);  };

I can use like this:

   var log;
   $.import("anton_test/util.xsjslib","util");
   ({log} = $.anton_test.util);
   log("Hello.");

This is my attempt to convert it similar to your example:

   // file util.xsjslib:
   /* module start */ (function() {

   function log(msg)
   {  $.trace.debug(msg);  };

   return {log};

   /* module end */})();

With this version, the test code above fails with:

                   log is not a function

because `log' is undefined. What did I do wrong?

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

[toc] | [prev] | [next] | [standalone]

#39706

I wrote:

> This is my attempt to convert it similar to your example:
>
>    // file util.xsjslib:
>    /* module start */ (function() {
>
>    function log(msg)
>    {  $.trace.debug(msg);  };
>
>    return {log};
>
>    /* module end */})();
>
> With this version, the test code above fails with:
>
>                   log is not a function

I fixed it be storing the result in a set of variables
({log}):

   const {log} =
   (function() {

   function log(msg)
   {  $.trace.debug(msg);  };

   return {log};

   })();

Michael, did you forget that in your example?

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

[toc] | [prev] | [next] | [standalone]

#39708

On Friday, March 19, 2021 at 11:08:48 AM UTC-5, Anton Shepelev wrote:

> I fixed it be storing the result in a set of variables 
> ({log}): 
> 
> const {log} =
> (function() { 
> 
> function log(msg) 
> { $.trace.debug(msg); }; 
> 
> return {log};
> })(); 
> 
> Michael, did you forget that in your example?

No, I just don't know how the platform's import mechanism works.
The modern standard is for the importing code to dictate the name and not the module itself.

Does `$.import(...);` return a value, or is it only a side-effect?

[toc] | [prev] | [next] | [standalone]

#39714

Michael Haufe:

> No, I just don't know how the platform's import mechanism
> works.  The modern standard is for the importing code to
> dictate the name and not the module itself.
>
> Does `$.import(...);` return a value, or is it only a
> side-effect?

I quoted a working example in the initial post:

   $.import("anton_test/util.xsjslib","util"); // import module
   $.anton_test.util.log("Log from library."); // invoke a function

Futhermore, a couple of posts above I provided a working
example of a library and its usage:

>    // file util.xsjslib:
>    function log(msg)
>    {  $.trace.debug(msg);  };
>
> I can use like this:
>
>    var log;
>    $.import("anton_test/util.xsjslib","util");
>    ({log} = $.anton_test.util);
>    log("Hello.");

You can also see the official documentation:

   Using Server-Side JavaScript Libraries:
   https://help.sap.com/viewer/d89d4595fae647eabc14002c0340a999/1.0.12/en-US/8a9cdd1242654ccd86ba113630e77830.html

As I understand from all of the above, it is a side effect.

> The modern standard is for the importing code to dictate
> the name and not the module itself.

Do you mean CommonJS modules (require) or ECAMScript modules
(import)? I think they both accept the name of the module
being imported.

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

[toc] | [prev] | [next] | [standalone]

#39720

On Saturday, March 20, 2021 at 5:32:32 AM UTC-5, Anton Shepelev wrote:
> Michael Haufe:
> > The modern standard is for the importing code to dictate 
> > the name and not the module itself.
> Do you mean CommonJS modules (require) or ECAMScript modules 
> (import)? I think they both accept the name of the module 
> being imported. 

Modules don't have a name they only have a path. The code that imports 
dictates what the name will be. We just generally use the provided definitions
as is for simplicity:

```
class Point2 {
    constructor(x, y) {
        this.x = x
        this.y = y
    }
}

export default Point2
```

```
import Point2 as Point from '<module-path>'
```

```
const Point = import("<module-path>");
```

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import>

[toc] | [prev] | [next] | [standalone]

#39707

On Friday, March 19, 2021 at 10:11:25 AM UTC-5, Anton Shepelev wrote:
> Michael Haufe:

> > Does the following code throw an error? 
> > 
> > ``` 
> > class Foo{} 
> > ```
> No, it works. 

Well, I guess I could be thankful for small favors. 

> Why are you writing in Markdown?

1. To make clear what is code and what is a comment about the code
2. More than JavaScript is used in this group in discussions. There is also TypeScript, ActionScript, and others.

```javascript
...
```

```typescript
...
```

The above I find more straightforward than what used to be common:

<script> ... </script>

<script type="text/javascript">
...
</script>

<script type="text/typescript">
...
</script>

That implies that the code is being used in a webpage is probably not true. 

> > If it does then I suspect some implementation of 
> > ECMAScript 5 is what's being used. There are no modules 
> > or classes in that version.
> As I wrote, it does recognise the `import' statement, but 
> fails with: 
> 
> import declarations may only appear at top level of a module 
> 
> presumably because it cannot treat .xsjs files as modules.

Which makes sense as they mention the *.xjslib extension.

> > I think the approach is to do it the old school way: 
> > [...]
> 
> This looksj rather complicated to me: the library consists 
> of the result of the execution of an anonymous function. I 
> have tried this approach with my test library, but failed. 

Since you verified that it's newer than ES5 you can't ignore my suggestion.
The modern module approach is more appropriate.

> Here is my original working library: 
> 
> // file util.xsjslib: 
> function log(msg) 
> { $.trace.debug(msg); }; 

Shouldn't you use the `export` statement since modules are supported?

> I can use like this: 
> 
> var log;
> $.import("anton_test/util.xsjslib","util");
> ({log} = $.anton_test.util); 
> log("Hello."); 

I think every variable is automatically exposed in this style. No module private.

> This is my attempt to convert it similar to your example: 
> 
> // file util.xsjslib: 
> /* module start */ (function() { 
> 
> function log(msg) 
> { $.trace.debug(msg); }; 
> 
> return {log}; 
> 
> /* module end */})(); 
> 
> With this version, the test code above fails with: 
> 
> log is not a function 
> 
> because `log' is undefined. What did I do wrong? 

The legacy module approach is not assigning variables to the global scope, it returns an anonymous object.
So on the importing side you would have to do an extra step to reference the "exported" values.

Since you confirmed that at least some ES6 features are available, you can ignore my example and try something more
modern:

```
function log(msg) { $.trace.debug(msg); }; 

export default log
```

or for multiple exports:

```
function log(msg) { ... }; 
function hello(msg){  ... }; 

export {hello, log}
```

[toc] | [prev] | [next] | [standalone]

#39715

Michael Haufe to Anton Shepelev:

> > Why are you writing in Markdown?
>
> To make clear what is code and what is a comment about the
> code

I see. Most of the time it seems sufficient simply to write
the code down after a vertical space. When doubt is
possible, I will also indent the code block on the left.

> More than JavaScript is used in this group in discussions.
> There is also TypeScript, ActionScript, and others.

One can also indicate the language in the prose.

> The above I find more straightforward than what used to be
> common: The above I find more straightforward than what
> used to be common:
> <script> ... </script>
>
> <script type="text/javascript">
> ...
> </script>
>
> <script type="text/typescript">
> ...
> </script>

Did anybody in this newsgroup use to post pieces of
JavaScript code inside HTML tags? That was terrible, indeed.
They must have been confusing Usenet articles that discuss
the code and actual web pages that use it.

> > As I wrote, it does recognise the `import' statement,
> > but fails with:
> >
> >    import declarations may only appear at top level of a module
> >
> > presumably because it cannot treat .xsjs files as
> > modules.
>
> Which makes sense as they mention the *.xjslib extension.

That extenstion is reserved for libraries, whereas the
actual server-side applications must be .xsjs, and I can't
seem to use the `import' statement in .xsjs  because of the
error quoted above. If I rename the main file to .mjs, the
error goes away, but HANA XS no longer "serves" them,
considering them as data files rather than JavaScript
sources to be executed. That is very strage and illogical.

> Since you verified that it's newer than ES5 you can't
> ignore my suggestion.  The modern module approach is more
> appropriate.

I do not ignore them. I just can't follow them :-)

> Since you confirmed that at least some ES6 features are
> available, you can ignore my example and try something
> more modern:
>
> ```
> function log(msg) { $.trace.debug(msg); };
>
> export default log
> ```
>
> or for multiple exports:
>
> ```
> function log(msg) { ... };
> function hello(msg){  ... };
>
> export {hello, log}
> ```

I will try it on Monday, but I think it will complain again
that `export' can only occur at the top level of a module,
because in its self-contradictory opinion a file is not a
module unless has one of the unsupported extensions .js or
.mjs. I will let you know.


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

[toc] | [prev] | [next] | [standalone]

#39721

On Saturday, March 20, 2021 at 5:51:57 AM UTC-5, Anton Shepelev wrote:
> Michael Haufe to Anton Shepelev:

> > Since you verified that it's newer than ES5 you can't 
> > ignore my suggestion. The modern module approach is more 
> > appropriate.
> I do not ignore them. I just can't follow them :-)

Sorry, typo. I meant you _CAN_ ignore my suggestion since a newer version is available.

> > Since you confirmed that at least some ES6 features are 
> > available, you can ignore my example and try something 
> > more modern: 
> > [...]
> I will try it on Monday, but I think it will complain again 
> that `export' can only occur at the top level of a module, 
> because in its self-contradictory opinion a file is not a 
> module unless has one of the unsupported extensions .js or 
> .mjs. I will let you know. 

I don't have high hopes to be honest. I'm glad I have yet to have to deal with that platform professionally.
Knowing the results of your experiments would be good to see regardless

[toc] | [prev] | [next] | [standalone]

#39754

Michael Haufe to Anton Shepelev:

> > I will try it on Monday, but I think it will complain
> > again that `export' can only occur at the top level of a
> > module, because in its self-contradictory opinion a file
> > is not a module unless has one of the unsupported
> > extensions .js or
>
> I don't have high hopes to be honest. I'm glad I have yet
> to have to deal with that platform professionally.

You don't have to, at all :-)

> Knowing the results of your experiments would be good to
> see regardless

Nothing doing. It is some kind of crippled NodeJS
implemtened on top of normal NodeJS under the hood.  If the
modern module syntax, which is comparable in power, if not
in clarity, to that of the Modula language, were supported,
they would not have to provide their own import mechanism,
but I am glad that have at least managed to make that
work...

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

[toc] | [prev] | [next] | [standalone]

#39740

Michael Haufe (TNO) wrote:

> On Friday, March 19, 2021 at 10:11:25 AM UTC-5, Anton Shepelev wrote:
>> Why are you writing in Markdown?
> 
> 1. To make clear what is code and what is a comment about the code
> 2. More than JavaScript is used in this group in discussions. There is
> also TypeScript, ActionScript, and others.

I find your backticks more confusing than helpful (and increasingly so), 
especially as we have format string literals now which are also delimited
by backticks.
 
-- 
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.

[toc] | [prev] | [next] | [standalone]

#39742

On Monday, March 22, 2021 at 3:14:19 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote: 
> 
> > On Friday, March 19, 2021 at 10:11:25 AM UTC-5, Anton Shepelev wrote: 
> >> Why are you writing in Markdown? 
> > 
> > 1. To make clear what is code and what is a comment about the code 
> > 2. More than JavaScript is used in this group in discussions. There is 
> > also TypeScript, ActionScript, and others.
> I find your backticks more confusing than helpful (and increasingly so), 
> especially as we have format string literals now which are also delimited 
> by backticks.

Noted. I'll play around with extended whitespace in the future to see how that reads.

[toc] | [prev] | [next] | [standalone]

#39744

Michael Haufe (TNO) wrote:

> On Monday, March 22, 2021 at 3:14:19 PM UTC-5, Thomas 'PointedEars' Lahn
> wrote:
>> Michael Haufe (TNO) wrote:
>> > On Friday, March 19, 2021 at 10:11:25 AM UTC-5, Anton Shepelev wrote:
>> >> Why are you writing in Markdown?
>> > 
>> > 1. To make clear what is code and what is a comment about the code
>> > 2. More than JavaScript is used in this group in discussions. There is
>> > also TypeScript, ActionScript, and others.
>> 
>> I find your backticks more confusing than helpful (and increasingly so),
>> especially as we have format string literals now which are also delimited
>> by backticks.
> 
> Noted. I'll play around with extended whitespace in the future to see how
> that reads.

ISTM that if ever a newsreader will be written that supports syntax 
highlighting out-of-the-box, it is more likely to support (GitHub-flavored) 
Markdown’s indentation to produce monospaced texts than (GitHub-flavored) 
Markdown’s backticks, because it is much easier to parse and there is less 
potential for false positives. (If I would write one, I would seek to 
support that; not necessarily requiring 4 leading spaces, though.)

<https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#code>

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

[toc] | [prev] | [next] | [standalone]

#39850

Thomas 'PointedEars' Lahn:

TL> ISTM that if ever a newsreader will be written that sup-
TL> ports syntax highlighting  out-of-the-box,  it  is  more
TL> likely  to support (GitHub-flavored) MarkdownТs indenta-
TL> tion to produce monospaced texts than  (GitHub-flavored)
TL> MarkdownТs backticks, because it is much easier to parse
TL> and there is less potential for false positives.  (If  I
TL> would  write one, I would seek to support that; not nec-
TL> essarily requiring 4 leading spaces, though.)

But it will not be compatible  with  other  newsreaders  and
with  the  Usenet medium in general, which is plain text. It
is much better simply to produce well-formatted plain  text,
using  good  text  editors  (e.g. Vim) or standard tools for
typesetting plain text, such as GNU Troff, in which I format
all  my  messages. The quote above, for example, demostrates
my own Groff macro for Fidonet quotations.

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

[toc] | [prev] | [next] | [standalone]

#39700

On Thursday, March 18, 2021 at 11:21:14 AM UTC-5, Anton Shepelev wrote:
> Hello, all 
> 
> It looks like in the system for which I need to write 
> server-side JavaScript, neither CommonJS nor ECMAScript 
> modules are supported, but it provides its own module system 
> that works as shown below: 
> 
> $.import("anton_test/util.xsjslib","util"); // import module 
> $.anton_test.util.log("Log from library."); // invoke a function 
> 
> Is it somehow possible to have all the functions from `util' 
> available in the current scope, so that I could invoke them 
> by their names: log("Hello"), rather than, say, 
> util.log("Hello"), without enumerating them in a 
> destucturing assignment. If analogies with other languages 
> can help, then it would be like `uses` in Borland Pascal, 
> `using static` in C#, or `#include` in C. 

Are you using node js?

<https://nodejs.org/api/esm.html>

Did you name the file *.mjs ?

[toc] | [prev] | [next] | [standalone]

#39739

Anton Shepelev wrote:

> It looks like in the system for which I need to write
> server-side JavaScript, neither CommonJS nor ECMAScript
> modules are supported, but it provides its own module system
> that works as shown below:
> 
>    $.import("anton_test/util.xsjslib","util"); // import module
>    $.anton_test.util.log("Log from library."); // invoke a function
> 
> Is it somehow possible to have all the functions from `util'
> available in the current scope, so that I could invoke them
> by their names: log("Hello"),

I think you mean the _local execution context_ instead, as the current scope 
is somewhat loosely defined as it extends to the global execution context.

Modules were introduced precisely to avoid the problems that your wish 
typically produces (what if there is a log() etc. defined in the execution 
context already?).

> rather than, say, util.log("Hello"),

While there is at least one fancy way to do this for several and selected 
properties only (which a custom module system might provide), the simple 
code

  const util = $.anton_test.util;

(or

  var util = $.anton_test.util;

to be backwards-compatible), is literally the best that you can do,
in general.

Note that

  const log = $.anton_test.util.log;

is NOT equivalent because “$.anton_test.util.log()” may use “this” to refer 
to “$.anton_test.util” which will refer to the global object, or (in strict 
mode) be the “undefined” value, if you then call “log()”.  The equivalent 
variant would be

  const log = $.anton_test.util.log.bind($.anton_test.util);

but when emulated for backwards compatibility (and maybe even when 
Function.prototype.bind() is available as a built-in), this comes at the 
price of reduced runtime efficiency when it is is called.  So just to be 
able to write “log” instead of “util.log” hardly appears to be worth it.

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

[toc] | [prev] | [next] | [standalone]

#39743

Anton Shepelev wrote:

>    $.import("anton_test/util.xsjslib","util"); // import module
>    $.anton_test.util.log("Log from library."); // invoke a function
> 
> Is it somehow possible to have all the functions from `util'
> available in the current scope, so that I could invoke them
> by their names: log("Hello"), rather than, say,
> util.log("Hello"), 

(Again: No.)

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));

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));

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 – the following code would be equivalent to the 
code above:

  const util = $.import("anton_test/util.xsjslib","util");
  util.log("Log from library.");

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.");
  });

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

[toc] | [prev] | [next] | [standalone]

#39748

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]

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web