Hi Doug, I'm so much pleased that you are the devils advocate. The point of view you have presented is somehow a trap - I'll explain this in the end of my reply.
I must agree with your point of view : creating is slow, destroying is even slower. But then, why we are on the mailing list? To find solutions. I've read all the thread about cloning components. First answer that comes into my mind is to clone stuff - I know it's stupid, but it's 1st solution. I really don't think is about nice architecture, but only about the flexibility. I usually speak to people that Flex suffered two paradigm changes, which I'm sure. Never took into account how many objects were created (because each developer creates something that you cannot control as an architect). Spark is faster then Halo, just because a small change in terms of thinking :) isn't it ? And Halo, compared to 1.5 is totally something else, isn't it (again) ? Where is the trap in being devils advocate : in that rule that says "prefer composition over inheritance". Well, I cannot argue against this one, because I haven't formulated it. Probably they were right. Probably the were not. I think there is 50-50 chance that someone is right. Unless the gang of four have changed their minds... On Mon, Jan 23, 2012 at 6:43 PM, Doug McCune <d...@dougmccune.com> wrote: > Just one counter-thought to play devils advocate a bit. One thing you have > to consider is performance, especially on something like UIComponent that > drives every little thing in your app. And in general, creating lots of new > Objects is slow (and disposing of them can also be slow due to the GC). > Overall I think most people see the benefit of a highly-composited > UIComponent that lets you define only the necessary functionality and lets > you swap out each little bit of behavior with another. However, if you end > up with all UIComponents creating 100 new objects each time a UIComponent > is initialized, you may be trading a nice architecture for performance. The > big consideration, I think anyway, when deciding on what should be moved to > composition, is what pieces would we want to turn off by default? Focus is > a good example. If there are a lot of cases where we want focus off (even > to the point where that would be default and you'd have to turn it on > explicitly), then I love the idea of stripping 99% of the focus code out of > UIComponent and using something like a FocusBehavior. But if it's going to > be on by default, and used in most cases, then all we've done is introduced > the creation of a new Object into all UIComponents. > -- http://www.badu.ro
