Hi Przemek,
Probably some RT errors from function call should be eliminated
for flexible usage. I never though about this problem so far
and when I was adding hashes to harbour I simply replicated
most of RT errors which exists in xHarbour.
What I've suspected.
You've just accepted autoadd in assign because you have quite nice
example of these feature used for i18n translation tables and so
far you haven't created any code which can benefit from autoadd
in access and you still think about hash items like like about some
type of static storage.
This feature is usable when hash is used as backed to collect some
results.
F.e. I want to collect information about quantity of articles sold:
Thanks for these hashing examples. In this sense they are
basically a small in-memory database table with a unique key.
Nice!
does not exists in the hash array. F.e. In the 1-st report above
I may want to group some type of articles together and rest
present individually. With this feature it's enough to change
the line with:
hReport[ FIELD->ARTICLE ] += FIELD->QUANTITY
to:
hReport[ hGroups[ FIELD->ARTICLE ] ] += FIELD->QUANTITY
but I can also use:
hReport[ hb_hKey( hGroups, FIELD->ARTICLE ) ] += FIELD->QUANTITY
Instead of adding new attribute to hashes.
This is a bit mind bending at first, but I get the idea :)
More elegant / compact than using arrays, for sure.
It cannot because NIL is also valid hash item value so it will
not be usable in all cases. But of course it does not mean that
we cannot remove RT error from hb_hGet() and document it as expected
behavior. If someone prefers functions call instead of faster h[key]
then probably he has some special reasons for this. One of such reason
can be missing RT error.
Experienced hash users should say the final word.
[ As a non-experienced one, I'd vote to drop similar
RTEs from functions. ]
xhb compatibility is not a concern BTW, because it uses
different function names anyway.
Because you asked to translate most of them. At the beginning
this implementation was using xHarbour compatible API. Anyhow
I do not think we have to be strictly compatible with RTE in
such functions.
It was not a complaint. Renaming has a nice side effect that
Harbour functionality is easy to detach from any xhb
heritage (meaning we're not restricted by xhb). If we happen
to bend any hash functions too far, we can just add the old
version to xhb.lib with the fully compliant functionality
and without any extra mapping tricks. xhb users should decide
what counts as "too far", and they'll most probably let us know.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
