Przemyslaw Czerpak wrote:
I think that's not the question, but rather if we want to
keep the RTE in hb_HGet() at all.
Exactly.
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.
Hi,
if you feel that some hash's properties or internals are heritage of
xHarbour, and it would be better to implement it another way, please do
it. I'm always for better implementation even with a little cost of
backward compatibility.
I've changed HB_HGet() to aHash[...] in my code, and have nothing
against changes related RTE behavior of this function.
One more remainder about i18n. We had a large discussion about i18n
internals, but that about it's public API? We have __*() functions:
__I18N_SAVE()
__I18N_LOADFROMMEMORY()
__I18N_LOAD()
__I18N_GETTEXT()
xHarbour has:
HB_I18NLOADTABLE()
HB_I18NSORTTABLE()
HB_I18NSAVETABLE()
I18N()
HB_I18NSETPATH()
HB_I18NGETPATH()
HB_I18NSETLANGUAGE()
HB_I18NGETLANGUAGE()
HB_I18NGETLANGUAGENAME()
HB_I18NGETBASELANGUAGE()
HB_I18NGETBASELANGUAGENAME()
HB_I18NSETBASELANGUAGE()
HB_I18NINITIALIZED()
Current __*() prefix makes me understand, it is not the final version. I
would like to have final implementation of it. What should be the final
public API for i18n?
Best regards,
Mindaugas
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour