On Thu, Mar 1, 2012 at 2:05 PM, Michael A. Labriola < labri...@digitalprimates.net> wrote:
> >See, I have a problem with this. Why would we not want to do that? The > ideal scenario is keep the interface same/similar but support everything. > >Internally, we can do things efficiently. > > That assumes that the way it did work was ideal or even good in some > cases. I have no desire to make transitions harder for people but you also > don't want to couple all future development to the interface of the past. > To me having to replicate every property for border and layout out to a > component only to delegate it down to different pieces was a bad idea. I > would hate to have to always support it because we once did. > But mx is not the 'past' and spark is not the 'future'. If it were the past, mx components that have spark equivalents will not ship in the same SDK version. You cannot have two different sets of classes with the same names but different behaviors. This is a real problem with dev teams that are trying to upgrade from Flex 3 to 4+ I am sure I am not the only one that finds this mix-in highly confusing. Either we kill mx:Spacer when we introduce s:Spacer *or* we have both follow the same interface *or* we name them something different. What is the message we are sending to users of the SDK when there is so much inconsistency flying around? Maybe, I am completely off base here, but exactly what is the motivation of the spark component set? Is it the new skinning paradigm, or is it better performing versions of existing components or is it a completely different set of components that happen to have similar names? If this is a separate conversation, please reply in a new thread. Thanks, Om > > Mike > >
