I've explained how that could be avoided in a more generic way in the end of the paragraph - why cannot that be a solution? It's ultimately the same mechanism, as you would add event handlers, actually. If you think about old MXMLC code, you could even use the part that generated event handlers to do that. The benefit would be that: 1. You can later override this behavior by providing your own implementation of a function that generates child components. 2. Much easier to use, when creating same components w/o MXML. This is not entirely a foreign concept - all sorts of labelFunction's and itemRendererFunction's work in a similar way.
Imagine something like this: // compare to this._dispatcher.addEventListener("eventType", this.eventHandler); ? . . . this._navigator.addTab("tabTitle", this.makeTab); . . . protected function makeTab(title:String):Tab { var tab:Tab = new Tab(title); tab.setStyle("whatever", doesnt, matter); return tab; } Not ideal, but no additional objects are created + more experienced developers would be able to provide makeTab() implementation which can be smarter (same function for multiple tabs / generate content based on data). The makeTab() function may be identified through [DefaultProperty] metadata, for example. The generated "descriptor" on the other hand, is not reusable, it's just some amorphous chunk of data. Of course, it never was a good idea to extend MXML components, but this is not a requirement, given normal code generation, this limitation can be lifted. Best. wvxvw