The compiler will pick source over library compilation time stamp. Distributing libraries to customers that rely on monkey-patching is somewhat risky. If they turn on the use of RSLs, your monkey-patch may not get used. If they create a shell app that to load the app using your library and the shell uses the class you monkey-patched, again, the monkey-patched class won’t be used.
Monkey-patching should be a means of last-resort if you’re actually going to put in into distribution. It is fine if you are producing the final application and control the sources. I have helped hundreds of customers with 1000’s of problems and we’ve often found clever ways to avoid monkey-patching. In fact, I’ll bet I’ve recommended monkey-patching less than 6 times. On 3/23/10 10:21 AM, "tntomek" <[email protected]> wrote: So looks like the only way to monkey patch when using libraries is just to have copies of all the mx.* monkey patched files in ALL projects. Only be doing this will the compiler be happy and it doesn't consider those files as duplicates. --- In [email protected] <mailto:flexcoders%40yahoogroups.com> , "tntomek" <tnto...@...> wrote: > > Seems like monkey patching works when everything is included in 1 project but > not when using libraries. What happens when I have 2 projects and monkey > patch is in other one. > > i.e. > MainAppProject (contains MainApp.mxml) > -SomeLibraryProject (this has the monkey patch code, i.e. Button) > > Now in my MainApp.mxml I'm unable to reference my version of the code. > > I understand if I use RSLs I can force load my class first so runtime would > work, but how do I get compile time access to this class? What if I added a > new property (in library project) and I want to access that property from > MainApp? The compiler has no idea and I can't build. This forces me to make > the monkey patch class implement some interface that would guarantee compile > time changes, but this is getting way more complicated then it needs to. Any > other ideas? > > -Tom Gruszowski (http://tomek.me) > -- Alex Harui Flex SDK Team Adobe System, Inc. http://blogs.adobe.com/aharui
