On Tue, Sep 17, 2013 at 9:30 AM, Erik de Bruin <[email protected]> wrote:
> I say don't worry too much about backwards compatibility, that is > always a sure road to over complicating a piece of software. What I do > think should happen is to make the compiler 'selectable'... So you > compile with either the old one (default for some time), or the new > one. That way people can evolve new projects to use the new compiler, > but be able to make simple fixes to legacy projects using the old one. > > EdB > > How would this approach affect third party libraries? Thanks, Om > > > > > On Tue, Sep 17, 2013 at 5:04 PM, Alex Harui <[email protected]> wrote: > > Falcon is catching subtle coding issues that MXMLC didn't catch like > duplicate variable declarations, ambigous definitions and more. Therefore, > there is a good chance that when you compile an existing app with Falcon > you might have to fix some of your code. So far, I haven't seen anyone > want to make Falcon less 'strict'. > > > > But I just ran into an issue with resource bundles where the current > Falcon code reports a compile error if it can't find a bundle for a locale. > MXMLC seems to do some magic and makes the en_US bundle also act as the > bundle for the locale that is missing a bundle. It has to do that because > the SDKs currently throw an error if a locale is missing a bundle. > > > > But is that what we want? I would think you should get a warning if a > bundle is missing and the SDK should change its code so that if a bundle is > missing it just falls through to the next bundle in the locale chain, if > any. But such a change would mean that, if you compile an existing project > against an older SDK, even Apache Flex 4.10.0, your app may throw an error > if you are missing a bundle. > > > > Thoughts? > > -Alex > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl >
