> - one thing that is possible is actually to go in the other direction:
> to derive a stubbed out implementation from only the public interface
> declaration (since nothing in the public interface ever ref's the impl
> class, thus avoiding the apt dependency issue). This is nice for an
> initial stub of the control impl, but starts to break down in
> iterative dev scenarios (how can i regenerate my stubbed impl after
> i've actually modified some of the stub methods).
Yah, that's one of the primary hassles with code-generation in
general. I've seen it work nicely where you end up generating
AbstractFoo, which isn't intended to be edited, but rather sub-classed.
Basically, you get default no-op types of methods, and just override
in MyFoo as you need. This at least allows for nice TDD-style of
development. But I don't know how subclassing would figure in with
controls.
> If you think I'm missing or misunderstanding something, please let me
> know! Keep those ideas coming!
I'm personally controls-ignorant aside from what Dan has waved his hands
about. Though, I'll be learning more m'self over the next week or two
as I work on docs for'em.
-bob
