2008/2/29, Wayne K. [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
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?