• While I can’t seem to find the page you are linking to, I agree with your statement. In OOP there are 2 main paradigms: Composition and Inheritance. It seems the Flex team went overboard with the latter and never looked at creating functionality by composition, which seems to be the main theme of Flex 4.

  • I’m not sure how my post relates to this. Perhaps you can explain?
    I agree that UIComponent is huge and does a lot, mainly adding MXML support, working with mx.core.Container, supporting styles, focus, automatic measurement and layout, percentage sizing, effects, tooltips, and whatnot. There are other classes that do all of this stuff for a UIComponent, e.g. LayoutManager, StyleManager, EffectManager, etc., but a UIComponent still needs to hold its own state. We could have split UIComponent into multiple classes each of which would support this kind of functionality, and there are pros and cons to doing that (the API would get complicated). I’m sure the Flex framework team is looking at options here.
    One of the things I’d like to see is layout separated from containers like Box, Tile, etc.
    It’s not straightforward as it might seem. For example, an HBox needs a horizontalGap property. Where should this go? On the generic container or on the layout object. And how is it specified in MXML?
    Umm … yeah, more later ๐Ÿ™‚

  • @Manish: Your posts doesn’t have anything specific to this topic, however, it’s related to other thing – how some of assumptions are made by flex-framework? Your post did talk about a few things and you explained the “why” part ๐Ÿ˜‰
    Having said all that, flex-framework is cool and I am sure it’s getting better…
    I am sure, we would see more developers jumping in to make it much better, since it’s now open-source.