Filein revisited - solving issue 51 & 93 for 0.9.1...

Hey!

I am looking at my bugs (51 and 93) at:

https://github.com/NicolasPetton/amber/issues?milestone=2&state=open

...and they both have to do with .st fileIn optionally followed by js/st
exports (amberc).

Now, these two issues are effects from the simple fact that the export
phase does not know what the import (fileIn) phase actually filed in.
Since we are filing in "on top" of code potentially already in RAM (for
example using amberc to recompile Kernel or Compiler packages), this means:

        - Export can potentially export more code than was filedin. So if you
remove a method in any of the base Amber packages, it will not actually
get removed by amberc! (issue 93)

        - amberc does not know which packages an .st file touches, and thus
does not automatically know what packages to export in the export phase.
Today it just relies on the heuristics of the .st filename being the
package name. (issue 51)

Analyzing this a bit more it all comes down to two important use cases
of .st files (I think):

        - As a "patch". The st file can be hand crafted doing lots of funky
stuff or just being a "partial" fileout, for example a single class. Or
actually being more than one single package.

        - As a *single* *complete* package fileout including extensions. This
is the normal case.

In order for amberc to deal with issue 93 when compiling package
fileouts (single complete package) the compilation/filein phase needs to
track what it files in, and then optionally delete superfluous
methods/classes/extensions(!) that wasn't in the filein. A subsequent
export will then of course only contain what was just filed in.

If the superfluous delete operation is optional, then we can still
support the "patch" use case by turning it off. What should the
subsequent export then do? Well, we can use the tracking to know all
packages touched by the filein and then we can make complete exports of
all those packages, and thus we also solve issue 51.

We could also export *only* the stuff we just tracked, thus exporting a
"partial package", but I think this is a bad idea and will just come
back to haunt us, so I am opting to not implement that.

So... question to Amber community - do you understand/agree on this
course of action? :)

Of course, if I had implemented proper Deltas (as I still intend to do)
then all would be solved by Deltas instead of hackishly using .st files. ;)

regards, Göran

Prefer monolithic packages.