Discuss
  • Minimal Module System Proposal

Minimal Module System Proposal

# Brandon Benvie (13 years ago)

I am hesitant to call this "maximally minimal" because the driving force behind coming up with this varies significantly from what drove maximally minimal classes. The driving force for this is the realization that the module system is perceived as being not close enough to being finished for ES6, yet is agreed to probably be the most important feature that could end up in ES6.

The goal here is not to claim that all is lost with the module system in full, because I do think that's not a certainty yet. I do think it is a likely enough outcome that there should be a fallback to capture the most important parts and make sure that they do make it to ES6. I think these parts can be limited to a subset of the module system that is agreed upon and is the most important parts of it, without compromising any other the other "at risk" parts for the future.

The premise of my concept for a minimal foundation system rests on the following assumptions:

  • The import syntax that parallels with destructuring is favored and mostly agreed upon.
  • The most important part of the module system needed for ES6 is the ability to import internal modules ('@iter'...).
  • The points of contention about the current module system are mostly about exporting user modules (resolving, etc.).
  • Internal modules have no need for resolution/export specification, only import. Nor do they need any specification for special binding, since they will be immutable.

The proposal extends simply enough from those assumptions: Pieces of the module system specification that are needed to support loading internal modules should be prioritized over all else, and the expectation should be that this will definitely work in ES6:

import { Symbol } from '@symbol';
# David Herman (13 years ago)

On Feb 7, 2013, at 9:48 AM, Brandon Benvie <brandon at brandonbenvie.com> wrote:

The goal here is not to claim that all is lost with the module system in full, because I do think that's not a certainty yet. I do think it is a likely enough outcome that there should be a fallback to capture the most important parts and make sure that they do make it to ES6.

Thanks, but let's not jump to any conclusions. I'm the champion of modules and wasn't even able to be a part of the discussion for family reasons. We can't make any judgment about the status of modules, or plans for reacting to the status of modules, before I've had a chance to be a part of the conversation.

# Brandon Benvie (13 years ago)

I just want to clarify that what I've proposed is not any semantics that aren't in the module system. It's a prioritization of what pieces of the module system are important above the others. If the prioritization isn't needed, which I recognize it may not be, then what I said can safely be ignored.

# Kevin Smith (13 years ago)

Thanks, but let's not jump to any conclusions. I'm the champion of modules and wasn't even able to be a part of the discussion for family reasons. We can't make any judgment about the status of modules, or plans for reacting to the status of modules, before I've had a chance to be a part of the conversation.

+1 and congrats (I'm slinging a babe right now ; )

I'm confident that modules will make it - in my mind ES6 will fail if not. They are certainly more important than proxies and private names, and the sooner we coalesce around the syntax, the better everyone will feel. IMO, your previous proposal was almost right on. e.g.

doku.php?id=harmony:modules&rev=1332511079, gist.github.com/khs4473/4382710

I think we need to have a knock-down-drag-out discussion about URL and loader semantics. ; )

# Russell Leggett (13 years ago)

On Thu, Feb 7, 2013 at 9:25 PM, Kevin Smith <khs4473 at gmail.com> wrote:

Thanks, but let's not jump to any conclusions. I'm the champion of modules

and wasn't even able to be a part of the discussion for family reasons. We can't make any judgment about the status of modules, or plans for reacting to the status of modules, before I've had a chance to be a part of the conversation.

+1 and congrats (I'm slinging a babe right now ; )

I'm confident that modules will make it - in my mind ES6 will fail if not. They are certainly more important than proxies and private names, and the sooner we coalesce around the syntax, the better everyone will feel. IMO, your previous proposal was almost right on. e.g.

doku.php?id=harmony:modules&rev=1332511079, gist.github.com/khs4473/4382710

I think we need to have a knock-down-drag-out discussion about URL and loader semantics. ; )

In the home brewed module system that I've been using for the past 4 years or so, I started by basically stealing from Java - in a comment at the top of a file I do sort of java style imports:

/*

  • #import com.foo.bar.SomeClass */

It had the usual sort of Java style semantics (we're a Java shop, so this works for us). Along the way, I added support for importing java classes - this would basically do some java -> javascript model building magic and

exposing services, etc. The notation for it looks mostly the same except for:

/*

  • #import remote com.foo.bar.JavaClass */

The sort of import modifier "remote" in there is the difference. Its just a bit of meta-data, but it helped with resolution of the dependency. Along the way, I've also added "lazy" as a modifier, which helps know how to break apart the application when I do concatenation during the build.

I'm not suggesting this syntax or semantics, but it occurred to me that perhaps if we could work some metadata into an import statement it could be a way of giving additional information to the loader. Perhaps it could be used for url resolution. For example, the "cdn" flag would let the loader know to resolve the url to a cdn, etc.

# Brendan Eich (13 years ago)

Kevin Smith wrote:

Thanks, but let's not jump to any conclusions. I'm the champion of
modules and wasn't even able to be a part of the discussion for
family reasons. We can't make any judgment about the status of
modules, or plans for reacting to the status of modules, before
I've had a chance to be a part of the conversation.

+1 and congrats (I'm slinging a babe right now ; )

I'm confident that modules will make it - in my mind ES6 will fail if not. They are certainly more important than proxies and private names, and the sooner we coalesce around the syntax, the better everyone will feel. IMO, your previous proposal was almost right on. e.g.

doku.php?id=harmony:modules&rev=1332511079, doku.php?id=harmony:modules&rev=1332511079, gist.github.com/khs4473/4382710

I think we need to have a knock-down-drag-out discussion about URL and loader semantics. ; )

Question about the linked wiki page rev:

  Variant B: "module =" syntax

Is that the variant you favor?

# Kevin Smith (13 years ago)

Variant B: "module =" syntax

Is that the variant you favor?

Yes, because:

  • It aligns the URL visually to the right, which is consistent with the import syntax.

  • It makes it clear that we are binding an identifier to a (possibly external) module, as opposed to importing bindings from a module. I think we should avoid overloaded terminology where "import" can also mean "load".

# Brendan Eich (13 years ago)

Kevin Smith wrote:

     Variant B: "module =" syntax

Is that the variant you favor?

Yes, because:

  • It aligns the URL visually to the right, which is consistent with the import syntax.

  • It makes it clear that we are binding an identifier to a (possibly external) module, as opposed to importing bindings from a module. I think we should avoid overloaded terminology where "import" can also mean "load".

I like it best too, for those reasons.