John,
this looks interesting! I like the API-based approach (Reminds me of the
Clojure "boot" build system's tag line, "Builds are programs"[1]). It seems
you have been working on that for a while.
[1] http://boot-clj.com/
On Mon, Feb 15, 2016 at 9:28 AM, John Spackman <john-li...@zenesis.com>
wrote:
>
>
> The QxCompiler fixes are to do with dependencies – basically, the load
> dependencies of a Qooxdoo app are greatly complicated because classes can
> have a defer() method, which allows code to be run before the app is fully
> loaded. The way (I think/guess) that the generate.py does it is to
> recursively interpret the code in .defer() and all of the methods it calls,
> ie it tries to predict at compile-time what methods will be called at
> runtime so that it can make sure that the load order is correct. As you
> can imagine this is non-trivial, but IMHO this makes it easy for minor code
> changes to have a big impact on load order and to cause unresolvable
> recursive dependency issues.
>
> My solution is to not call the class .defer() method until all classes are
> loaded (that’s not strictly possible because some classes .defer() must be
> called, but the dependencies are a lot simpler). This solution needs a a
> couple of backwards compatible mods, mostly in qx.Bootstrap, and these are
> in the qxcompiler branch
>
> There’s bit more detail here:
> https://github.com/johnspackman/qxcompiler/blob/master/docs/Dependencies.md
>
What really complicates dependency inference is to find the transitive
closure for each (what you put as "recursively interpret the code"). But I
think you need that for both load-time and run-time dependencies alike.
This entails that any small change in far away code can have an impact on
the overall set of classes and their load order. (But only load-time makes
cyclic dependencies an issue, and that's probably what you care about).
Once recursive analysis is in place, adding the symbols from .defer() to
the load-time dependencies is easy as you write. So it's not that .defer()
makes the general mechanism of treating dependencies more difficult - it
just enlarges the set of load-time dependencies, and hence increases the
risk of not being able to create a partial order for all the classes. But
.defer() is not particularly more problematic than, say, static
initializers in the class, or #require's.
But I see how .defer() is a good target to minimize on that risk.
T.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
