Maybe we should revisit that decision? I think we did it in the belief that some of the debugger interfaces required it (e.g., globalValue). But recently André found a work-around for another case where we were relying on all classes being public (the implementation of subclassof) which allows it to work even for non-public classes. In the interest of minimizing the perturbation of debugging, perhaps we should remove the 'auto-public' feature (assuming we can still debug)?
On 2010-05-27, at 22:53, Henry Minsky wrote: > I thought we'd be able to let users link their lzo's against > 'external' lzo's in swf10, even if the compiler flags didn't > match, but it turns out that if you try to link a non-debug version > against a debug version, you get compiler errors > because the debug versions of classes always forces methods to be > 'public' , and that means they have different signatures than > the non-debug versions, as far as the flex compiler is concerned. > > This just means that when someone compiles a swf10 lzo that is > subclassing stuff from another external lzo, they'll have > to make sure they are linking against an lzo which was compiled with > the same compiler flags. > > I guess forcing all methods to be public is not such a great idea, or > rather, it will have consequences when > sublassing from precompiled libraries. > > > > -- > Henry Minsky > Software Architect > [email protected]
