incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: s:Spacer (was Re: Missing Spark components)
Date Thu, 01 Mar 2012 23:05:25 GMT
On Thu, Mar 1, 2012 at 2:05 PM, Michael A. Labriola <
labriola@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message