Hello, Thanks for taking a look at the patch so quickly... I have a response for each below.
1 - Extension methods on System.* namespace. As a guideline this is strongly discouraged. "Just because you can doesnt mean you should" Good point, I moved them into Castle.DynamicProxy.SilverlightExtensions and added the needed usings in their respective places in my working set already... 2 - The RWLock code from Mono. I'd rather have - like I mentioned before - our special locker on Castle.Core that use RWLocker (or preferably RWLSlim) for .net and Monitor for SL. I didn't want to push too far down implementing this on my own because of a lack of knowledge of what the RWL was doing/how it's being used and am not all that familiar with Monitors, however this sounds like a good time to learn so I will start to take a look... 3 - The new exceptions added. Either we always throw specific exceptions or generic ones. Not sure what you mean by this, the added exceptions are specific exceptions. Or are you referring to in silverlight it might throw "MySpecialException" and in the full framework it would throw "ApplicationException"? If this is your concern that's great, can we replace the ApplicatoinExceptions with MySpecialException? I didn't do that in the full framework version because I didn't know if there was anything out there that depended on those exceptions being thrown... Thanks again, Jason On Sat, Dec 27, 2008 at 6:41 PM, hammett <[email protected]> wrote: > > I reviewed it. Overall it looks fine. The only things that prevents me > from applying are > > 1 - Extension methods on System.* namespace. As a guideline this is > strongly discouraged. > "Just because you can doesnt mean you should" > > 2 - The RWLock code from Mono. I'd rather have - like I mentioned > before - our special locker on Castle.Core that use RWLocker (or > preferably RWLSlim) for .net and Monitor for SL. > > 3 - The new exceptions added. Either we always throw specific > exceptions or generic ones. > > I'm willing to apply the patch as soon as we discuss and fix these points. > > Thanks for the effort > > On Sat, Dec 27, 2008 at 2:51 PM, Staxxx <[email protected]> wrote: > > Hello All, > > DISCLAIMER: I'm not very familiar with the Castle project in general. My > > goal is to get a mocking framework supported under silverlight and the > only > > two open source frameworks I know of (Moq & Rhino...) depend on the > dynamic > > proxy so I figure we start here... > > I've attached a patch that I hope could work, however, below I'll list a > few > > things that still need work in silverlight or in general. > > 1. Should double/tripple check the logic of the > > included ThreadSafeDictionary<TKey,TValue> > > 2. In MethodEmitter.CopyParametersAndReturnTypeFrom() there is a method > call > > not exposed to Silverlight because I don't know how to get > > at baseMethod.ReturnParameter.GetRequiredCustomModifiers() and > > baseMethod.ReturnParameter.GetOptionalCustomModifiers(). > > 3. I left some compiler directive #warning's in the code at places that > > either need some extra thought or need to be just excluded for > silverlight > > 4. I couldn't figure out (in an afternoon) how to successfully sign an > > assembly in silverlight (ModuleScope.GetAssemblyName()) there's some > > thoughts there, but I'm leaving any of the unit tests that depend on that > > failing currently. > > 5. There are a number of Tests that relied > > on SerializableClassTestCase.SerializableInterceptorSelector and I just > > excluded those from silverlight, didn't dig into what they were testing > and > > if there should be silverlight coverage for their purpose. > > 6. Also I can't say I know or followed the assembly naming standard > > correctly or how the AssemblyInfo.cs is created/used... > > Please let me know how this patch looks, what needs special attention, or > if > > anyone can help with any of what I listed above. > > Thanks, > > Jason Jarrett > > > > > > > > > -- > Cheers, > hammett > http://hammett.castleproject.org/ > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
