My point was that I'm putting a place holder method to spit out the
require() statements. For now it is just using the imports that were
added by the visitor.
Note, I haven't looked at the visitor adding these imports yet, since
this walking is coming from a built SWF, we may already have what we
are looking for! ... resolved dependencies. I will need to test this,
I will let you know.
So to restate, I am not actually looping through the "imports" I am
using imports that were added to the emiter during visits from the
reducer. We will see.
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
Sounds good to me, too.
So that would mean no support for *-imports in the first iteration?
It would also mean that you would even have to import classes that are
implicitly imported (same package or top-level package) to have all needed
goog.require() statements generated, but I think that would be okay for the
time being. You would only have to add imports that cause no trouble for
"normal" compilation, so you can still have a single-source-multi-target
code base. This is extremely important for testing that we implement the
correct semantics.
On Fri, Dec 7, 2012 at 12:30 PM, Erik de Bruin <e...@ixsoftware.nl> wrote:
> Ok, understood but for now, I AM going to add the imports explicitly
> declared as a writer implemented method. After we get the code "looking"
> right we can worry about actual "implications" of what is written.
Sounds like a plan. The way I understand the Closure Builder to work I
think it will clean out unused 'requires' anyway, pretty much like I
imagine the AS compilers clean out unused 'import'. Eventually we want
to write out only what we need, if only to reduce complexity and avoid
mistakes, but I agree that is not a priority at this time.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
