Hi Tomas,
> > database file number is encoded in a kind of hexadecimal number, which
> > uses @, A, B .. O instead of 0, 1, 2, .. F. The object ID is encoded in
> > octal. This has the advantage that the dash '-' as a separator is not
> > needed any more, because the file number digits 0 .. 7 are different
> > from the letters A .. O. With that, an object might look like {1},
> > {123}, {A45}, {CDE7654321} and so on.
>
> why do you need to mix hexadecimal and octal? I imagine having the
> second part in hex would be possible too. E.g. using 0-F for the
> second part and G.. for the first would work too and the names would
> be shorter?
This would be an option, but visually the different parts (file number
and object ID) would not differ so clearly (e.g. {GHFEC} vs. {GH7754}).
A perhaps more important reason is that the file number part has 16 bits
and thus fits nicely into four hexadecimal digits, while the object ID
part is 42 bits, which is not a multiple of 4 but of 3 and thus lends to
an octal representation.
BTW, the letters A through O for hexadecimal numbers correspond to the
first and last letter of the classical greek alphabet (Alpha / Omega),
representing the universe. ;-)
The length of the printed representation of external symbols is not
important any more, as the internal format (stored in the DB,
transferred with PLIO) is binary anyway. They are typed or printed only
during debugging.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
