Someone said this several messages back but I don't think everybody saw that since people are talking about when there is a s:Spacer.
There is an entry in the spark manifest that points to mx:Spacer so s:Spacer is mx:Spacer. It has already shipped so you can't/shouldn't turn it into something else. Carol On 3/1/12 6 :05PM, "Om" <bigosma...@gmail.com> wrote: >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 >> >>
