9df12235a6
This change first and foremost adds a MuIL export node (ast.Export);
this is for re-exporting members of other modules, potentially under
a different name.
This works by simply by associating a name with a fully qualified token
name that, when binding, can be re-resolved to the real target. This
should be sufficient for expressing everything we need from MuJS.
In addition to that, there is an initial cut at basic re-exports; this
is the form where you would say:
export { some, nifty as cool, stuff } from "module";
In this example, we end up with two Export nodes: one maps "some" to
"some/module", "cool" to "some/nifty", and "stuff" to "some/stuff".
Note that we have not yet implemented two other variants.
First, we will want to support the "export all" variety, e.g.
export * from "module";
Instead of supporting wildcards in MuIL -- which would result in the
odd attribute that you couldn't know the totality of a module's exports
without also examining its dependencies (possibly recursively) -- we
will require the compiler to map the "*" to a concrete list of Export nodes.
Second, we also want to support named exports from the current module.
That is to say, export clauses without `from "module"` parts. E.g.
let some = ...;
let nifty = ...;
let stuff = ...;
export { some, nifty as cool, stuff };
This is less important because you can always export members using the
more familiar `export <decl>` syntax (which is already recognized by MuJS).
But of course, we will want to support it eventually. It is slightly more
complex, because we will need to use static typing to resolve the exported
members to their types -- e.g., variable, class, interface -- and in fact
this could lead us to re-exporting whole modules in their entirety.
Both of these two will require marapongo/mu#46. Since so much is piling up
behind this, I will likely begin biting this off soon. I also believe that
we may want re-export nodes, Export, to carry a specifier that indicates whether
the target is a class, variable, or sub-module.
|
||
|---|---|---|
| cmd | ||
| docs | ||
| examples | ||
| lib | ||
| pkg | ||
| sdk/javascript | ||
| tools/mujs | ||
| .gitignore | ||
| .gitmodules | ||
| glide.lock | ||
| glide.yaml | ||
| main.go | ||
| Makefile | ||
| README.md | ||
Mu
Mu is a framework and toolset for creating reusable stacks of services.
If you are learning about Mu for the first time, please see the overview document.
Building and Testing
To build Mu, first clone it into a standard Go workspace:
$ mkdir -p $GOPATH/src/github.com/marapongo
$ git clone git@github.com:marapongo/mu $GOPATH/src/github.com/marapongo/mu
A good default value for GOPATH is ~/go.
Mu needs to know where to look for its runtime, library, etc. By default, it will look in /usr/local/mu, however you
can override this with the MUPATH variable. Normally it's easiest just to create a symlink:
$ ln -s $GOPATH/src/github.com/marapongo/mu /usr/local/mu
There is one additional build-time dependency, golint, which can be installed using:
$ go get -u github.com/golang/lint/golint
And placed on your path by:
$ export PATH=$PATH:$GOPATH/bin
At this point you should be able to build and run tests from the root directory:
$ cd $GOPATH/src/github.com/marapongo/mu
$ make
This installs the mu binary into $GOPATH/bin, which may now be run provided make exited successfully.