incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Kwiatkowski <>
Subject Re: What namespace should new components go in?
Date Tue, 31 Jul 2012 02:53:36 GMT
I personally like #2.  And I don't see having another namespace as a
disadvantage -- we already have mx, fx, and s, let alone any custom ones
that people add.


On Mon, Jul 30, 2012 at 10:06 PM, Justin Mclean <>wrote:

> Hi,
> Reposting (and expanding) as suggested under a new topic to make it clear
> this discussion is about namespaces. This has been discussed on the list
> before but no clear consensus was reached.
> In the patches branch I've created a new apache target in the build script
> to compile an an apache.swc to place new components in. It uses a new
> namespace - This has been in the patches
> branch for several months. The PostCode validator and format classes
> currently use this namespace and I would like to move them into trunk,
> followed closely by Mike's collection classes.
> What are people preferred option with new components and namespaces?
> 1. Use existing mx and spark namespaces
> Advantages: No new namespaces required.
> Disadvantages: New components mixed in with old and compiled into existing
> swcs making them larger etc, hard know what's new over 4.6 SDK. Not always
> obvious which namespace mx or spark a new component should go into.
> 2. Place components under a single new namespace called
> Advantages: All new components have a new ant target, new swc and
> namespace so easy to see what is new in the SDK and if a project is using
> Apache Flex. Work already done in patches branch. Namespace is valid URL
> and was suggested by a mentor.
> Disadvantages: It's a new namespace.
> Example of how a user of the SDK would see it/use it:
> (also see patches branch)
> 3. Place components under a single new namespace other than one suggested
> in 2.
> See 3 for advantages and disadvantages.
> 4. Place components under multiple new namespaces
> Advantage: No need to decide if it's a mx or spark component.
> Disadvantages: Lots of new namespaces. More work on build scripts.
> 5. Don't care.
> In which case I'll just check in what I've done in the patches branch.
> Thanks,
> Justin

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