Hashids that you need but error

[jenson]

Hello, lazarus compile the hashids function show few error as below. which one can repair it.

-----
HashIds.pas(26,29) Error: Duplicate identifier "Hash"
HashIds.pas(26,29) Hint: Identifier already defined in HashIds.pas at line 22
HashIds.pas(33,26) Error: Duplicate identifier "Salt"
HashIds.pas(33,26) Hint: Identifier already defined in HashIds.pas at line 18
HashIds.pas(33,46) Error: Duplicate identifier "MinHashLength"
HashIds.pas(33,46) Hint: Identifier already defined in HashIds.pas at line 19
HashIds.pas(33,75) Error: Duplicate identifier "Alphabet"
HashIds.pas(33,75) Hint: Identifier already defined in HashIds.pas at line 17
-----

HashIds
=======

HashIds for Embarcadero Delphi Alexandria 11 based on Ivan Akimov's hashids for Pascal.

Hashids is a small open-source library that generates short, unique, *non-sequential* ids from numbers. Unlike traditional Hashes it is reversible if you use the same salt and alphabet. It is not encryption and does not provide any security to the encoded numbers. There are no _collisions_ because the method is based on integer to hex conversion. As long as you don't change constructor arguments midway, the generated output will stay unique to your salt.

This implementation is tested to be compatible with other [implementations](https://hashids.org/).

## Notes on usage
1. Use the same salt and alphabet to encode as decode.
2. Do not try to encode negative numbers. It won't work. The library currently supports only positive numbers and zero. If you're trying to use numbers as flags for something, simply designate the first N number of digits as internal flags.
4. Do not encode strings. We've had several requests to add this feature — "it seems so easy to add". We will not add this feature for security purposes, doing so encourages people to encode sensitive data, like passwords. This is the wrong tool for that.
5. Do not encode sensitive data. This includes sensitive integers, like numeric passwords or PIN numbers. This is not a true encryption algorithm. There are people that dedicate their lives to cryptography and there are plenty of more appropriate algorithms: bcrypt, md5, aes, sha1, blowfish. Here's a [full list](https://en.wikipedia.org/wiki/List_of_algorithms#Cryptography).

See http://www.hashids.org/ for more information and other implementations.

[Thaddy]

Mode objfpc is more strict than Delphi: the freepascal compiler is right. You can either compile in mode delphi instead of mode objfpc or you can change the code to prefix the private fieldnames with F, as it should have been done and don't call a parameter hash if you have a function hash etc.... Will attach a version for mode objfpc. Also note that allowing duplicate names, even in mode delphi, may not work in 3.2.0, probably ok in 3.2.3, works for sure in trunk.
The code is inundated with duplicate identifiers and other sloppy code. Makes you wonder about the quality.
Attached a version with part of the sloppyness corrected and still delphi compatible.
But as I wrote, you may just get away with compiling in mode delphi, that works at least in trunk. Since fairly recently FPC supports Delphi's sloppy duplicate identifier behavior.
The attached version works in mode objfpc too, since all duplicate identifiers are resolved.
I also got rid of the misuse of self.<X>which I replaced with F<X> as it should be.

[Thaddy]

The examples work both in Delphi and in Freepascal now.

[marcov]

Thaddy: for umpteenth time, a bit less aggressive please.

[Thaddy]

Marco, where am I agressive? I just fixed the code? Which was bad. Also for Delphi.
It is still 100% compatible but without the nuesanse of duplicate declarations.
I explained what was wrong, why it is wrong and fixed it.
Without values.
[edit]
Only possible opinion is that I wrote it is bad code, which is not opinion but fact for the reasons I showed.
There is a lot more wrong - in the translation to object pascal -, but at least now it works.
I am not inclined to fix every little detail, because the subject does not interest me. Bad code does.
BTW: the original code, not the pascal code, shows such naivity that I wonder why anybody should/want to use it. It is clearly written by a NOOB, not a pro. Take the time to examine it, like I did.
(although it is a good example of what the effect of a salt is for educational reasons)

[Thaddy]

Forgot one basic thing to fix: alphabet in wrong order. Should be numerics first, capitals second, lowercase last.
But the compiler optimizes that, probably...(ASCII order )
Anyway useless code.
( Apart from being a good example of salts and how that works )
I suspect the alphabet was already in the wrong order in the original.(It is)

Running up a ladder and having to go back everytime that you have reached a certain step and start all over again and that two times. Really good programming....

Ignore that code. Even after I fixed it.
Even the original code is not up to standards.
The pascal code is a brave attempt but suffers from bad initial code.
You can not blame the translator in this case. The translation is not that bad, but the initial code is.
Which makes that the translation copied the same ignorance from the original.