On Sat, Dec 27, 2008 at 9:03 PM, Staxxx <[email protected]> wrote: > Hello, > With the ReaderWriterLock could we use the one that is commented out in the > Castle.Core SilverlightExtensions?
Sure, you can use that. Just change its name and namespace. > Are there issues with using that as > opposed to something else? > Sorry for my ignorance, I'm a little over my head w/ how to write my own > ReaderWriterLock... > Also, I took that same version and all the unit tests pass with it (however > I don't know if there any multi-threaded tests there...) > Thoughts? > > On Sat, Dec 27, 2008 at 7:01 PM, Staxxx <[email protected]> wrote: >> >> 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/ >>> >>> >> > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
