If we stopped munging the method signatures it would certainly make it much more convenient for peple to compile and debug with lzo's that contain precompiled swf10 libraries in them.
On Sat, May 29, 2010 at 7:15 PM, P T Withington <[email protected]> wrote: > 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] > > -- Henry Minsky Software Architect [email protected]
