Thanks for (re)pointing that out Carol. Looks like it was done with http://bugs.adobe.com/jira/browse/SDK-28369
-Ryan On Thu, Mar 1, 2012 at 11:28 PM, Carol Frampton <cfram...@adobe.com> wrote: > 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 > >> > >> > >
