useful?

docs/developer/SecretAPIs.txt

@@ -0,0 +1,52 @@
+FACT: The compiler is a complex beast.
+
+Sometimes its hard to test that widget you've stuck five levels deep down in the 
+compiler infrastructure, sometimes you want to ship some experimental function
+that is only enabled in certain environments.
+
+The solution is that we design the code for testability and configurability.
+
+Q. What does this mean?
+
+It means that throughout the complex are public fields or methods that are
+exposed to enable some components to have their behaviour changed, from a
+testcase or hosting environment (AJDT).  Andy has put a few of these in
+over the last few months, and Adrian has just put one in - I don't think
+we can get around the need for these things.
+
+Q. How do I identify them?
+
+I keep forgetting where I've put them, so from now on they are all marked
+with a task tag of SECRETAPI.  When we have a little time to rest and
+reflect on what we've been doing we should look at whether they can be
+consolidated into an uber-control API module that centralises control of
+all these secret buttons and widgets.
+
+Q. Give me an example?
+
+1. The structure model produced post build is a complex series of data
+structures.  Incremental compilation is complex too.  Incremental
+repairs to the structure model to ensure it stays up to date when
+incrementally compiling are particularly complex so there is a flag
+to turn on incremental repairs.
+
+2. Testing what happens when processing incremental state is difficult
+as there is no nice API to the state object that you can call at the
+appropriate point in your test.  The StateListener instance that
+can be set on the State object enables you to get callbacks when
+certain things happen - for example if a change is detected on a 
+classpath entry the compiler is looking at.  Doing it via an optional
+listener means we don't have to record endless amounts of
+information whilst state processing that would only be consumed
+by the test infrastructure.
+
+Q. Can I add them wherever I like?
+
+NO! They are a last resort if you can't test something cleanly
+*or* its so experimental you don't want to destabilise existing consumers
+of the compiler.  For example the state management for incremental
+compilation is currently configurable (defaults to off) as it has an
+impact on memory usage and probably on other IDEs - when we've resolved
+these issues we can look to making ON the default.  For any non-test
+related secret APIs you should think about when they ought to be made
+default !