2008/2/29, Wayne Kelly <[EMAIL PROTECTED]>: > Thanks for raising this. I was aware of the performance issue and my > original implementation did use the TransformBlock method, but I switched to > an explicit buffer approach in order to support cloning of digest objects. I > didn't think/realize it was possible to clone .NET Crypto objects. > > I see you use the MemberwiseClone method. Firstly, I thought this was a > protected member, how are you able to directly call it on your context > objects? Secondly, is the shallow copy that MemberwiseClone performs going to > give us the correct cloning semantics?
I think visibility is enforced by compiler, not runtime. For example, one can access private members by reflection or by bytecode generation. In general, IronPython can access protected members by default, and private members when explicitly asked. Hash implementations are fully managed (in .NET and Mono), and shallow copying by MemberwiseClone does give the correct semantics *now*. hashlib.py is currently in production use. However, I don't think that MemberwiseClone gives correct semantics is guaranteed by explicit documentation. > P.S. I notice your module is implemented in Python - I hadn't even > contemplated the idea of implementing these libraries in Ruby - I guess > because I'm a C# developer. Do people think we should rewrite these extension > libraries in Ruby? Writing in Ruby does simplify some boilerplates code, doesn't it? -- Seo Sanghyeon _______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
