Am Fri, 22 Jun 2012 13:33:41 +0400 schrieb Dmitry Olshansky <dmitry.o...@gmail.com>:
> On 22-Jun-12 13:11, Johannes Pfau wrote: > > Pull request #221 and #585 both introduce modules for a new std.hash > > package. As those already change API compared to the old std.crc32 > > and std.md5 modules we should probably decide on a common interface > > for all std.hash modules. > > > > These are the imho most important questions: > > > > Free function (std.crc32) vs object(std.md5) interface > > ----------------------------------------------------- > > I think we need a object based interface anyway as md5, sha-1 etc > > have too much state to pass it around conveniently. > > > > Yup. > > > Structs and templates vs. classes and interfaces > > ----------------------------------------------------- > > It's common to use a hash in a limited scope (like functions). So > > allocating on the stack is important which favors the struct > > approach. > > That's useful especially if you use one type of hash always. (e.g. > SHA-1 a-la git) > > > However, classes could also be allocated on the stack with scoped. > > > > Too shitty for widespread use. +Extra indirection on each block(?). > > > Classes+interfaces have the benefit that we could provide different > > _ABI_ compatible implementations. E.g. MD5 hashes could be > > implemented with D/OpenSSL wrapper/windows crypto API and we could > > even add a configure switch to phobos to choose the default > > implementation. Doing the same with structs likely only gives us > > API compatibility, so switching the default implementation in > > phobos could cause trouble. > > > > 3rd option. Provide interface/class based polymorphic wrapper on top > of structs. Come on! It's D, we can find reasonable compromise. Yeah we could indeed do that. This complicates the API a little, but it's probably still the best solution. I think I'll implement the structs first, the polymorphic wrapper can be added later.
