On 2021-08-06 12:20 a.m., Martijn Lievaart wrote: > > Op 06-08-2021 om 03:13 schreef Darren Duncan: >> On 2021-08-04 1:01 a.m., Smylers wrote: >>> Let's debate a specific proposal on its own merits, and not discard it, >>> or derail the discussion, in the hope of something bigger and vaguer >>> that possibly could happen in the future. >> >> I fully agree. >> >> As the saying goes, the perfect is the enemy of the good. >> >> The current discussion should just focus on whether the current proposed new >> solution is significantly better than what Perl has now and thus whether Perl >> switching to it would be an improvement. >> >> Consideration of other algorithms can be their own separate discussions if or >> when someone comes up with a specific example and makes a case it is better >> than the winner of the current discussion, including that someone has already >> committed to do the work etc. > > Yes, but a question that may be asked is, can this be generalized to support > different algorithms easily, so programmers can choose the hashing algorithm at > runtime. And if it can, is it worth to take such a broadening of the scope on at > the same time as handling the current proposal. If it is easy to implement, it > should be looked at. > > I suspect the answer to this is a firm no, but it never hurts to look at this. > Anyone who knows the internals who can say something about that? I would say that at this stage the best argument for having that feature of hashing algorithm choice is: 1. If it turns out from measuring that some common use cases perform way better with the current algorithm and others perform way better with the new one, and users would then benefit from being able to choose to tune their scenarios. 2. Also implementing the ability to choose isn't too much effort or has too poor trade-offs of is own. 3. If going forward the added maintenance cost of two algorithms rather than one is worth it. -- Darren DuncanThread Previous | Thread Next